Manu Sporny: came out of the discussion about the Drupal use cases; specifically the thing we've called language maps; which is about something else
… this proposal attempts to solve that, along with other aspects of the issues regarding mappings in JSON-LD
Niklas Lindström: This proposal is sort of a unification of the various ideas we've had on how to use 'maps' to map certain keys to certain values where the keys do not represent actual properties of the object. [scribe assist by Manu Sporny]
Manu Sporny: This is a generalization of the @language map proposal - ISSUE-133
Niklas Lindström: This @annotation suggestion doesn't define the meaning of the key and does not bind it to anything - you specifically can't map it to RDF. The reason for that is that there are JSON "in-the-wild" cases where you index stuff in a JSON object in order to have easier access to it. [scribe assist by Manu Sporny]
Niklas Lindström: This seems to fit the Drupal use case. [scribe assist by Manu Sporny]
Niklas Lindström: There is a part on whether this should survive expansion. We could do it unobtrusively. [scribe assist by Manu Sporny]
Niklas Lindström: This proposal does NOT, in the current shape, address the Microdata shape - I think we should first discuss the proposal, then we could discuss the shape of Microdata separately. [scribe assist by Manu Sporny]
Niklas Lindström: In the Microdata case, the term does not have a value... the keys do - it's an inverse of the general mapping situation. [scribe assist by Manu Sporny]
Gregg Kellogg: changing the mechanism to put the annotation key in the values of the properties (the latter suggestion) is better. It preserves the shape.
… I'm still concerned about retaining information that does not map to RDF
Gregg Kellogg: Changing the proposal to put the @annotation key in the property is much better and helps preserve the shape better. I'm still concerned that we're basically retaining information - creating a data model that is not an RDF data model. This is the shape of language maps, so I could go along with doing that. [scribe assist by Manu Sporny]
Gregg Kellogg: In terms of the last point that Niklas had made of applying this to Microdata. I think we could use the same mechanism to address the Microdata use case. [scribe assist by Manu Sporny]
Lin Clark: this proposal is actually what we originally expected, so it should work for us
… and it doesn't use any additional blank nodes
Gregg Kellogg: it requires to add container annotations, but not to declare language keys
Manu Sporny: two parts of this proposal: 1) having the annotation properties, 2) making sure that this can round-trip
Niklas Lindström: I want to emphasize what I think works for the round-tripping - it seems to me that if round-tripping would work, you could add annotations by post-processing expanded form. Then you could use compaction to make sure this mapping just "happens". The corner-case with that is that given the example has 3 nodes w/ @ids, regular compaction would not frame them in any way - you would end... [scribe assist by Manu Sporny]
Manu Sporny: ...up with a @graph keyword with the same nodes, unless the @annotation keyword is "scheduled" to be added.
Manu Sporny: one other corner case: in expanded forms, you have three items with annotations and a fourth without: what happens then?
Markus Lanthaler: the term wouldn't match
General discussion on the two proposals
Markus Lanthaler: if we introduce this, we should make it roundtripplable
David I. Lehn: will properties that are duplicated in multile annotations override each other or show up as multiple values for the same property?
PROPOSAL: If '@container'; '@annotation' is added to the JSON-LD Syntax, the feature MUST be round-trippable from .compact() to .expand() back to .compact()
Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +0
Lin Clark: +1
François Daoust: 0
Niklas Lindström: +1 (knowing it's not the cleanest thing..)
David I. Lehn: +0
François Daoust: (I like the idea but wouldn't mind if it's not round-trippable)
RESOLUTION: If '@container': '@annotation' is added to the JSON-LD Syntax, the feature MUST be round-trippable from .compact() to .expand() back to .compact()
PROPOSAL: Add '@container'; '@annotation' to the JSON-LD Syntax.
Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +0.8
François Daoust: +1
Markus Lanthaler: +0.8
Lin Clark: +1
David I. Lehn: +1
RESOLUTION: Add '@container': '@annotation' to the JSON-LD Syntax.
Lin Clark: no outstanding concerns at the moment. Of course, need to test the implementation.
Manu Sporny: any other concerns from Drupal?
Lin Clark: none at the moment
Markus Lanthaler: Lin, what about ISSUE-195? Still needed?
Lin Clark: Markus, not if this is supported
Markus Lanthaler: do you still the graph container?
Lin Clark: not necessary if this is implemented
Markus Lanthaler: I suggest to put 195 on hold then
Markus Lanthaler: PROPOSAL 1: Allow a term to be mapped to null (either directly or by setting @id to null). This mapping is stored in the active context and also overwrites a @vocab mapping meaning that the term does not expand to an IRI and will thus be dropped when expanding.
Markus Lanthaler: PROPOSAL 2: If a term is mapped to null (either directly or by setting @id to null) remove its definition from the active context. This means that when a @vocab mapping exists, the term is expanded using the @vocab IRI in expansion and will thus not be dropped.
Gregg Kellogg: proposal 1 is to explicitly prevent a term from being expanded by @vocab by setting it to null
Gregg Kellogg: some other options: we could use blank nodes as terms, since they are not allowed
Niklas Lindström: There might be a problem with that in the future, if RDF 2.0 allows properties to be blank nodes. I've seen N3 notation like that - poor mans reification by having a property inline as a blank node. [scribe assist by Manu Sporny]
Manu Sporny: +0.5 (PROPOSAL 1) , + 0.4 (PROPOSAL 2) [scribe assist by Manu Sporny]
Markus Lanthaler: +0 (PROPOSAL 1) , +0 (PROPOSAL 2)
François Daoust: +1 to proposal 1, 0 to proposal 2
Niklas Lindström: My @rev feature in my compact JSON needs this feature, it's based on a real-world use case. [scribe assist by Manu Sporny]
RESOLUTION: Allow a term to be mapped to null (either directly or by setting @id to null). This mapping is stored in the active context and also overwrites a @vocab mapping meaning that the term does not expand to an IRI and will thus be dropped when expanding.
Markus Lanthaler: PROPOSAL 1: Remove the term node reference as it is not needed; one term (currently node definition) is sufficient.
Markus Lanthaler: PROPOSAL 2: Rename node definition to node object because 1. it doesn't actually “define” a node, and 2. to make more explicit that it is a kind of JSON object
Gregg Kellogg: I hope that removing the notion of a node reference won't bite us
Markus Lanthaler: an object with only an id still defines a node I think
Gregg Kellogg: when flattening, a node with just an id, with no references to it, is just saying there is a point, disconnected from the rest of the graph
Manu Sporny: same concerns as gregg. the reason for the difference is because the terms are used in the algoritms
Markus Lanthaler: only 7 occurrences
Markus Lanthaler: at least 5 of these are used together
Markus Lanthaler: in the minor cases where it matters we can be explicit about there not being any other properties (in a node reference)
Gregg Kellogg: I wonder whether not having a concept for it may be a problem
Gregg Kellogg: sort of like the triple and iri in RDF concepts
Gregg Kellogg: the iri itself is not in the graph
(by itself)
Manu Sporny: since this is editorial, we can always fix it if it becomes a problem
Manu Sporny: +0.5 (PROPOSAL 1), +0.5 (PROPOSAL 2) [scribe assist by Manu Sporny]
Markus Lanthaler: +1 to both
Gregg Kellogg: +0.5/+0.5
Niklas Lindström: +0.5/+0.5
François Daoust: +1 to both proposals (but wouldn't mind keeping the distinction between "node object" and "node reference" either)
RESOLUTION: Remove the term node reference as it is not needed; one term (currently node definition) is sufficient.
RESOLUTION: Rename node definition to node object because 1. it doesn't actually “define” a node, and 2. to make more explicit that it is a kind of JSON object
Topic: ISSUE-180: Make link to RDF more apparent in the specification
Markus Lanthaler: we diverge where we allow unconnected nodes, so they don't form triples in the end
… proposal is a "SHOULD NOT" about their use
… and the same for blank nodes as properties; processors must lower-case language tags, and that blank nodes id:s are scoped to the document
Markus Lanthaler: from richard: With 1 and 2, I am unconvinced that having those features (blank edges and unconnected nodes) in the JSON-LD data model is actually useful, and would prefer if the algorithms would either remove them, or translate them into something that can be expressed in the RDF data model.
Gregg Kellogg: regarding blank edges, this *may* become part of RDF in the future, so I'd prefer the use of SHOULD NOT for those
… regarding unconnected nodes, it's algorithmically difficult to prevent those in expand and compact. It *is* done in the toRDF. We could also do the same in flatten, although that requires checking every node object to see if a node is used
... it is more complex, but allows us to remove these dangling references
… (just a thought)
Manu Sporny: agrees with the reasoning. but the issue is complex; I think the language should address it sufficiently (plus making the algorithms explicit about what they support).
PROPOSAL: Add the following statements to the specs - a) "Authors SHOULD NOT use unconnected nodes (a node definition that does not contain any properties) in JSON-LD documents." b) "Authors SHOULD NOT use blank nodes as edge labels." c) "JSON-LD processors MUST normalize all language tags to lowercase when processing documents via the JSON-LD Algorithms." d) "Blank node labels are scoped to the JSON-LD document."
Markus Lanthaler: it can still be said that the nodes exist (c.f. the open world assumption)
Manu Sporny: +1
Gregg Kellogg: +
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
François Daoust: +1 but note proposal c) is for API doc
RESOLUTION: Add the following statements to the specs: a) "Authors SHOULD NOT use unconnected nodes (a node definition that does not contain any properties) in JSON-LD documents." b) "Authors SHOULD NOT use blank nodes as edge labels." c) "JSON-LD processors MUST normalize all language tags to lowercase when processing documents via the JSON-LD Algorithms." d) "Blank node labels are scoped to the JSON-LD document."
Markus Lanthaler: could be compared to e.g. rdf:Description rdf:about=""/ in RDF/XML.
Markus Lanthaler: about whether if json-ld is a serialization of a graph or a dataset
… a graph is a set of triples, a dataset is a set of graphs
… under consideration is if this distinction should be made by using different mime-types
… the proposal is that we should make clear what json-ld serializes
Markus Lanthaler: PROPOSAL 1: normatively define the concept of a JSON-LD Dataset. In the context of a Dataset, a JSON-LD document including only a default graph serializes a Dataset with only a default graph. A JSON-LD document describing a default graph and/or one or more named graphs serializes a Dataset with default and named graphs.
Markus Lanthaler: PROPOSAL 2: define an alternate extension and mime-type for describing JSON-LD documents serializing Datasets, as distinct from the existing type which serializes a single graph. Named graphs used within a graph serialization are flattened into a single graph, and produce only a single graph when parsed.
Markus Lanthaler: PROPOSAL 3: Normatively define the concept of a "JSON-LD document".
Markus Lanthaler: PROPOSAL 4: Add in the RDF-mapping section Richard is writing a statement that JSON-LD documents serialize datasets (which may contain only a default graph)
Markus Lanthaler: PROPOSAL 5: Do not introduce additional mime types or file extensions to distinguish between JSON-LD documents containing only a default graph from documents containing multiple graphs.
Markus Lanthaler: PROPOSAL 6: A JSON-LD document which does no @graph, or containing @graph only as part of the top-level node definition without an @id property serializes a an RDF Graph.
Markus Lanthaler: PROPOSAL 7: A JSON-LD document containing any node definition having both @graph and @id serializes an RDF Dataset.
Markus Lanthaler: PROPOSAL 8: The @graph keyword may only be used in top-level node definitions, i.e., node definitions which are not the value of a property of another node definition.
Niklas Lindström: Every other RDF format in use, apart from TRiG, only represent graphs... my concern is how this will be treated by SPARQL Read/Write APIs and perhaps other RW RDF approaches by Linked Data Platform. [scribe assist by Manu Sporny]
Markus Lanthaler: Richard's votes:
Markus Lanthaler: PROPOSAL 1: +1
Markus Lanthaler: PROPOSAL 2: -1
Markus Lanthaler: PROPOSAL 3: +1
Markus Lanthaler: PROPOSAL 4: +1
Markus Lanthaler: PROPOSAL 5: +1
Markus Lanthaler: PROPOSAL 6: -1 because a dataset without named graphs is not an RDF graph.
Markus Lanthaler: PROPOSAL 7: a fact
Markus Lanthaler: PROPOSAL 8: no opinion
Niklas Lindström: For instance, in SPARQL, you can put a document to a specific IRI, the Quad-store uses the IRI that the POST went to as the graph name. There are parts of this that I'm concerned about because we don't know how Datasets will be used in the future. [scribe assist by Manu Sporny]
Gregg Kellogg: my implementation deals with this by depending on the user
… if I put a JSON-LD document into a graph container (into a named graph), it is turned into a set of triples which are put into the destination graph
… the resolution is to let the behavior depend on this
… the container determines what happens: if it takes graphs, the graphs in the dataset are preserved, otherwise they are merged
Manu Sporny: the web payments only use named graphs for digital signatures
Manu Sporny: we don't use sparql or similar which cares about quads/datasets
Manu Sporny: can we consolidate this proposal and defer for now?
ACTION: Gregg to create a unified proposal or two for ISSUE-182.
François Daoust: [OK to defer. Overall, I would prefer to stick to something as simple as "a JSON-LD document serializes a dataset" without exceptions based on the presence/absence of "@graph" at key positions in the document]
Topic: ISSUE-189: Support of {@type:{@id:xxx}} constructs
Markus Lanthaler: Do we allow this? "@type":{"@id":"A"}
Markus Lanthaler: The proposal is to disallow it
PROPOSAL: Do not support constructs like "@type";{"@id";"A"} in the spec as that would suggest to developers that they could include other properties of the type there as well.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Richard Cyganiak: +1 to proposal [scribe assist by Markus Lanthaler]
Markus Lanthaler: +1
François Daoust: +1 (I don't think that converts into any change in the syntax spec, as it's already forbidden by the grammar)
RESOLUTION: Do not support constructs like "@type":{"@id":"A"} in the spec as that would suggest to developers that they could include other properties of the type there as well.
Topic: ISSUE-133: Add '@language' container type (related to ISSUE-159)
Gregg Kellogg: PROPOSAL 3: The values of the key-value pairs of a language map MUST be strings or arrays of strings. When expanded, the strings are tagged with the language specified by the key. When compacting, only language-tagged strings will match a term that has a "@container": "@language" mapping. Terms that have a "@container": "@language" mapping MUST NOT be type-coerced.
Markus Lanthaler: given that we have annotation, we can restrict to language-tagged strings
Manu Sporny: one question: this decisions makes it so that only plain text strings can be used in language maps?
Gregg Kellogg: For expansion, I would say that non-string (or array of string) values of a property with language maps are expanded to use the property, but loose the language association. That is, they don't round-trip.
François Daoust: now with container: annotation, the container: language seems unneeded
Gregg Kellogg: this does address the issue that values in different languages become convenient to reach; for instance in wikipedia, 10 different languages for a title become easy to access
Markus Lanthaler: "title" : { "en": 1 } doesn't round-trip since the value is not a string
… for consistency's sake, if we get data with bad shape, where non-regular strings aren't discarded, but not interpreted as having the language of the key
PROPOSAL: The values of the key-value pairs of a language map MUST be strings or arrays of strings. When expanded, the strings are tagged with the language specified by the key. When compacting, only language-tagged strings will match a term that has a "@container"
Markus Lanthaler: +1
Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
François Daoust: +1 (it's a bit confusing as similar to but less flexible than "@annotation" but I understand the need to support language in a special way)
RESOLUTION: The values of the key-value pairs of a language map MUST be strings or arrays of strings. When expanded, the strings are tagged with the language specified by the key. When compacting, only language-tagged strings will match a term that has a "@container": "@language" mapping. Terms that have a "@container": "@language" mapping MUST NOT be type-coerced.
Topic: ISSUE-178: Consider renaming JSON-LD API to JSON-LD Core Processing
Markus Lanthaler: PROPOSAL 1: Do not rename the JSON-LD API spec
Markus Lanthaler: PROPOSAL 2: Rename the JSON-LD API spec to "JSON-LD Core Processing"
Markus Lanthaler: PROPOSAL 3: Rename the JSON-LD API spec to "JSON-LD Algorithms and API"
Markus Lanthaler: PROPOSAL 4: Move Data Model and Grammar to the JSON-LD API spec, and rename it to "JSON-LD: Definitions, Processing and API".
Markus Lanthaler: PROPOSAL 4b: Move Data Model and Grammar to the JSON-LD API spec, and rename it to "JSON-LD: Definitions, Processing and API". Rename "JSON-LD Syntax" to something generic like "JSON-LD: JSON for Linked Data".
Markus Lanthaler: Richard's votes:
Markus Lanthaler: PROPOSAL 1: -0.7 (The meat of the spec is not the API, so the current title is false advertising.)
Markus Lanthaler: PROPOSAL 2: -0.2 (Why “Core”? Seems to be brainless and inappropriate copying of the RDFa spec name.)
Markus Lanthaler: PROPOSAL 3: -0.2 (“Algorithms” is just the style used to define the processing. If the processing was spelled out in prose, you wouldn't call the spec “API and Prose”. Or “API and Diagrams”. What's the purpose of the algorithms? That needs to go into the title.)
Markus Lanthaler: PROPOSAL 4: +0.99
Markus Lanthaler: PROPOSAL 4b: +1
Manu Sporny: web developers tend to go to the source - the core spec. not the primer
… primers tend to be fairly high-level [not containing all the needed details]
… what document will they naturally hit (from e.g. google)
Manu Sporny: what ever title is picked, has to convey the relevant message to the intended reader in a google hit
… for instance: "Introduction to JSON-LD" is better than 4b
Niklas Lindström: I think that the titles should convey to the audience that we want something that tells them to read the document. [scribe assist by Manu Sporny]
Gregg Kellogg: best title aside, richard's intent is valuable
… regarding the case of someone getting to the wrong document, a good introduction should send them to the right place
… so one normative document and one more informative note(?) sounds good
Manu Sporny: this seems like bike shedding though
Manu Sporny: thanks all for the fantastic session and for all of the hard work to close these issues! Great job everyone!