Markus Lanthaler: when reverse properties were introduced, we did that in a minimal way, restricting e.g. @container to @index
... this is problematic for deterministic compaction, by e.g. ensuring @set
... also, @type: @id makes sense since only IRIs/bnodes are valid subjects – but the form would not be deterministic if mixed references and objects with other values are used
... I've checked the spec and there are only four minor points which need to be altered, to be considered a bug fix in order to support deterministic shapes
... these to proposals will make this consistent with how other properties work
Manu Sporny: are there downsides other than no automatic type coercion?
Markus Lanthaler: only that the context becomes a bit larger if you only use references, since with this change you have to specify @type: @id explicitly
PROPOSAL: Allow "@container": "@set" for reverse properties.
Niklas Lindström: +1
Dave Longley: +1
Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
Vikash Agrawal: +1
RESOLUTION: Allow "@container": "@set" for reverse properties.
PROPOSAL: Remove the @type restriction for reverse properties. This also means that a reverse property won't be implicitly type-coerced to @id anymore.
Markus Lanthaler: +1
Dave Longley: +1
Manu Sporny: +1
Paul Kuykendall: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: was this marked as at risk?
Markus Lanthaler: the entire feature was it, yes
Gregg Kellogg: this fix is in response to LC feedback
Manu Sporny: and this is considered a bug fix for an inconsistency
RESOLUTION: Remove the @type restriction for reverse properties. This also means that a reverse property won't be implicitly type-coerced to @id anymore.
Topic: RDF and JSON-LD Alignment issue.
Manu Sporny: we've had a number of RDF/JSON-LD alignment discussions throughout this work
David Booth: Can we separate the issues of the re-definition of "Linked Data" from other alignment issues, to eat the elephant one piece at a time?
... we've tried to find an acceptable balance, but the last days” discussion show this is not the case
... let's focus on specific proposals to +1/-1 on
... there are some editorial and some normative suggestions. Maybe we can start with background on your major concerns, David (Booth)?
Sandro Hawke: yes
David Booth: let's focus on the (re)definition of Linked Data separately
Sandro Hawke: (leaving IRC)
... that term is very important in the semweb community, and it's important to not redefine it
... With respect to the normative stuff; based on discussions with gregg, the WG intended the RDF alignment to be normative originally..
... i.e. the mapping to the RDF model
... this is not apparent by reading the syntax spec
... it explicitly says that it is not normative. This sounds like an editorial issue.
... Separately, I also suggest that the skolemization of graph/predicate bnodes is made normative
Dave Longley: three issues: 1. linked data redefinition, 2. relationship to RDF model in syntax spec should be normative (editorial), 3. skolemization should be normative
Manu Sporny: so three issues in total: 1) Linked Data definition, 2) normative relation to the RDF model 3) normative skolemization [correct?]
Topic: Relationship to RDF model in syntax spec should be normative
Manu Sporny: I think the CG agrees in principle
Gregg Kellogg: as I recall, we tried to avoid circular dependencies
Manu Sporny: we did it since the API spec might not progress at the same rate
Sandro Hawke: I think david's wording from yesterday is that the mapping is provided normatively in the other spec; but the syntax spec doesn't reference it normatively
David Booth: making this reference normative would address my issue
David Booth: a question regarding the conformance statement, is that complete? let's leave that for now, to avoid confusiin
Gregg Kellogg: since we are on separate timelines, the RDF 1.1 is behind us, possibly slowing JSON-LD down [correct?]
Manu Sporny: so if we make the statement normative, that this is now to map to RDF, that is enough?
Manu Sporny: do we also need to reference to the RDF 1.1 concepts in this statement, in the syntax spec?
David Booth: I'm proposing we make this change: The normative algorithm for interpreting JSON-LD as RDF is specified in the JSON-LD Processing Algorithms and API specification [JSON-LD-API].
Markus Lanthaler: I would be fine with that change
David Booth: interpreting as RDF, and serializing as JSON-LD
Gregg Kellogg: think of how this would read if it were turtle: we don't want to paint a difference that's not there
David Booth: agreed
Sandro Hawke: in turtle and rdf/xml, we can just say parsing as RDF, but jn JSON-LD, it's more about converting to..
PROPOSAL: Add the following normative text to the JSON-LD Syntax specification: The normative algorithm for interpreting JSON-LD as RDF is specified in the JSON-LD Processing Algorithms and API specification [JSON-LD-API].
David Booth: +1
Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Markus Lanthaler: could you add "in section C. Relationship to RDF"?
Paul Kuykendall: +1
Dave Longley: +1 (but should align the language with the changes requested in the JSON-LD API spec)
Markus Lanthaler: +1, if this goes into section C. Relationship to RDF
Manu Sporny: we divided this up like this because we wanted to explain the tech clearly, and the best place for conversion is in the algorithms spec, because it is very detailed
David Booth: put pat hayes' point in an appendix?
RESOLUTION: Add the following normative text to the JSON-LD Syntax specification: The normative algorithm for interpreting JSON-LD as RDF is specified in the JSON-LD Processing Algorithms and API specification [JSON-LD-API].
Manu Sporny: though those details are not for the intended audience
David Booth: Make the following editorial change to clarify and move the mention of RDF slightly later in the document. Delete the sentence: "Developers that require any of the facilities listed above or need to serialize anRDF graph or dataset [RDF11-CONCEPTS] in a JSON-based syntax will find JSON-LD of interest.". Instead, add the following bullet item to the existing bullet list in section 1.1:
David Booth: - "Software developers who want to generate or consume Linked Data, an RDF graph or an RDF Dataset in a JSON syntax."
Manu Sporny: a parallell proposal is sandro's proposal
Manu Sporny: Sandro proposed: JSON-LD was designed to be compatible with Semantic Web technologies like RDF and SPARQL. People intending to use JSON-LD with RDF tools will find it can be used as another RDF syntax, like Turtle. Complete details of how JSON-LD relates to RDF are in Appendix C.
Sandro Hawke: I think I prefer david's proposal
David Booth: I would be fine with either one. I like Sandro's mention of Appendix C though.
Gregg Kellogg: I like both, sando's could go elsewhere
David Booth: +1 to using both, with sandro's later
Dave Longley: though "compatible with" might send the wrong signal about a difference that's not there
Gregg Kellogg: good to note that also JSON usage is taken into account
David Booth: yes, tweak sandro's to change "compatible with"
Manu Sporny: the note should be crystal clear that these are not considered as alternative technologies
Gregg Kellogg: JSON-LD allows you to write idiomatic JSON, but have it interpreted as RDF [scribe assist by Manu Sporny]
Gregg Kellogg: spell out that JSON-LD allows you to write idiomatic JSON, *and* to interpret it as RDF (c.f. RDFa allowing you to write HTML..)
Markus Lanthaler: david wood asked us to add that sentence at the end of the introduction (suggested to be deleted)
... we should not do that without consulting David Wood.
PROPOSAL: Make David Booth's bullet-point addition to the JSON-LD Syntax spec: " * Software developers who want to generate or consume Linked Data, an RDF graph or an RDF Dataset in a JSON syntax."
Manu Sporny: +1
Dave Longley: +1
Niklas Lindström: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
David Booth: +1
RESOLUTION: Make David Booth's bullet-point addition to the JSON-LD Syntax spec: " * Software developers who want to generate or consume Linked Data, an RDF graph or an RDF Dataset in a JSON syntax."
David Booth: Proposed revision of Sandro's text: JSON-LD was designed to be usable directly as JSON, but also as RDF (if desired), for use with other Semantic Web technologies like SPARQL. People intending to use JSON-LD with RDF tools will find it can be used as another RDF syntax, like Turtle. Complete details of how JSON-LD relates to RDF are in Appendix C.
Manu Sporny: making it clear that neither RDF nor SPARQL is needed to use JSON-LD, but also that it is designed to work as RDF
David Booth: JSON-LD was designed to be usable directly as JSON, with no knowledge of RDF, but was designed also to be usable as RDF (if desired), for use with other Semantic Web technologies like SPARQL. People intending to use JSON-LD with RDF tools will find it can be used as another RDF syntax, like Turtle. Complete details of how JSON-LD relates to RDF are in Appendix C.
PROPOSAL: Add spec text to the following effect into the JSON-LD Syntax specification: JSON-LD was designed to be usable directly as JSON, with no knowledge of RDF, but was designed also to be usable as RDF (if desired), for use with other Semantic Web technologies like SPARQL. People intending to use JSON-LD with RDF tools will find it can be used as another RDF syntax, like Turtle. Complete details of how JSON-LD relates to RDF are in Appendix C.
Niklas Lindström: +1 to that
Gregg Kellogg: +1
Dave Longley: +1
David Booth: +1
Manu Sporny: +1
Markus Lanthaler: +1... could probably go into design goals
Paul Kuykendall: +1
RESOLUTION: Add spec text to the following effect into the JSON-LD Syntax specification: JSON-LD was designed to be usable directly as JSON, with no knowledge of RDF, but was designed also to be usable as RDF (if desired), for use with other Semantic Web technologies like SPARQL. People intending to use JSON-LD with RDF tools will find it can be used as another RDF syntax, like Turtle. Complete details of how JSON-LD relates to RDF are in Appendix C.
David Booth: What about this change? 4. Without adding any earlier mention of RDF than the JSON-LD spec already contains, make other editorial changes as needed to avoid implying that JSON-LD is not necessarily RDF. (However it is fine to say that JSON-LD does not need to be *processed* as RDF.)
David Booth: Example: Change "Converting JSON-LD to RDF" to either "Interpreting JSON-LD as RDF" or "Converting a JSON-LD model to an RDF model".
David Booth: not say "converted to", but rather "interpreted as"
Markus Lanthaler: fine with "interpreting"
Dave Longley: yeah, that's fine
Gregg Kellogg: +1 to interpreting ...
Markus Lanthaler: algorithm names would sound a bit weird though
Dave Longley: For algorithms, maybe "produce RDF abstract syntax from JSON-LD"?
David Booth: What about making other editorial changes as needed to avoid implying that JSON-LD is not necessarily RDF. (However it is fine to say that JSON-LD does not need to be *processed* as RDF.)
Markus Lanthaler: dlongley, who understands what an abstract syntax is?
Markus Lanthaler: :-)
PROPOSAL: Make other editorial changes as needed to avoid implying that JSON-LD is not necessarily RDF.
Gregg Kellogg: +1
Niklas Lindström: +1
Dave Longley: +1
Manu Sporny: +1
David Booth: +1
Paul Kuykendall: +1
Markus Lanthaler: +1
RESOLUTION: Make other editorial changes as needed to avoid implying that JSON-LD is not necessarily RDF.
Markus Lanthaler: dbooth, pull requests are welcome :-P
David Booth: And this change? 5. At the beginning of appendix C insert: "JSON-LD is a _concrete RDF syntax_ as described in [RDF11_CONCEPTS]. Hence, a JSON-LD document is both an RDF document and a JSON document and correspondingly represents both an instance of the RDF data model and an instance of the JSON-LD data model."
Manu Sporny: though that hinges on the difference on bnode usage and native datatypes basically you can do those 4 bullet points in appendix c in JSON-LD, but not according RDF 1.1 concepts.
David Booth: so this is tied to the other topic
Gregg Kellogg: there are other differences, like the @ındex feature which are purely syntactical stuff
David Booth: but that's ok
Gregg Kellogg: though those could be considered part of the json-ld data model
Manu Sporny: like the native list and native numbers
Gregg Kellogg: but turtle has syntactically "native" lists
Dave Longley: can we just say: "JSON-LD can be interpreted as a concrete RDF syntax" ?
Dave Longley: since there's a mapping?
David Booth: but that's an effect of the syntactic form, which isn't a problem in relation to the abstract syntax
Manu Sporny: I don't see a problem either, but others in the RDF WG had...
Gregg Kellogg: the option to transform numbers to native json numbers could change this (to enable this interpretation of the model relationship)
Sandro Hawke: I think they complained because it wasn't true at the time. But I think we've just about fixed this, except maybe for skolemization.
David Booth: My understanding is that this wording does reflect the intent of the working group, and just makes it clearer.
Markus Lanthaler: So we got already a first response
PROPOSAL: Add spec text to JSON-LD Syntax. Appendix C: JSON-LD is a _concrete RDF syntax_ as described in [RDF11_CONCEPTS]. Hence, a JSON-LD document is both an RDF document and a JSON document and correspondingly represents both an instance of the RDF data model and an instance of the JSON-LD data model.
Manu Sporny: +0.5
Gregg Kellogg: +1
David Booth: +1
Niklas Lindström: +1
Dave Longley: +1
Markus Lanthaler: +0
Manu Sporny: sandro: +1
RESOLUTION: Add spec text to JSON-LD Syntax. Appendix C: JSON-LD is a _concrete RDF syntax_ as described in [RDF11_CONCEPTS]. Hence, a JSON-LD document is both an RDF document and a JSON document and correspondingly represents both an instance of the RDF data model and an instance of the JSON-LD data model.
Topic: Conversion of blank nodes to Skolemization IDs when going to RDF
David Booth: specify that **when JSON-LD is interpreted as RDF,** (i.e., when the JSON-LD model is converted to the RDF model) skolem IRIs MUST be generated using the well-known URI suffix "json-ld-genid" for any JSON-LD blank node that would otherwise be mapped to an RDF blank node in a position where an RDF blank node is not permitted. Conversely, when RDF is serialized as JSON-LD (or when an RDF model is converted to a JSON-LD model), skolem IRIs having the well-known URI suffix "json-ld-genid" SHOULD be serialized as JSON-LD blank nodes. Finally, register the well-known URI suffix "json-ld-genid", in accordance with RFC5785: http://tools.ietf.org/html/rfc5785
David Booth: BACKGROUND NOTE: The existing well-known URI suffix "genid" is for converting to/from RDF blank nodes (in positions where blank nodes are *permitted* in RDF), whereas "json-ld-genid" will be used for *avoiding* blank nodes (in positions where they are not allowed in RDF).
David Booth: some discussion about the well-known suffix name (sandro suggested another one I'm fine with), or use the existing name gen-id, created by the RDF WG. Though those would make it harder for streaming processors to directly convert to bnodes without looking at the context.
Sandro Hawke: I think it is always legal, specifically to convert skolemized IRIs
Sandro Hawke: I think it's better to use normal gen-id:s
Markus Lanthaler: you end up with heaps of clashing bnode id:s
Manu Sporny: this is the decentralized identification problem
David Booth: The whole point of well-known suffixes is to prevent clashes while allowing distributed minting of IRIs.
Manu Sporny: every time we discuss this, we go through the same line of argumentation. First we propose skolem IDs, then we note that skolem IDs can't be rooted in the same namespace, then we decide that skolem IDs need to be generated in a very specific way, then we back up to RDF Graph Normalization as the correct approach to the problem, then we throw our hands up because the problem is more complicated than we want it to be.
Manu Sporny: skolem id:S is not a solution to this probglem
David Booth: this is not true; it is a solved problem, based on the well known suffixes
Manu Sporny: if you control the domain, yes
... in that case, we cannot say that there is a specific domain space for thi
... if your system doesn't understand bnodes in these positions, you need a callback to provide a skolem id which is unique to your system
David Booth: and use that well-known suffix, so that it is predictably recognized
Markus Lanthaler: isn't that what we are currently saying in the spec?
Manu Sporny: it's not in the API
Markus Lanthaler: but the algorithm spec says this [correct?]
David Booth: my point is that it should say MUST replace them
David Booth: there is no RDF system which supports this
... the point is strict alignment
... if one person takes a JSON-LD document and serialize it into Turtle, and another person does the same, the result is essentially the same
... there is a difference between the JSON-LD blank node and RDF blank node
Markus Lanthaler: but you can use it in the object position and the graph id position at the same time
Gregg Kellogg: but since the graph id does not denote the graph, it's semantically not a problem
... in practise though, it would be
... the dictum should be that if a blank node is converted (skolemized) – *all* identifiers must be changed accordinly
Markus Lanthaler: so a skolemized iri is a bnode?
David Booth: no
David Booth: yes, it is a hack to make it work around a shortcoming in the RDF model
David Booth: this is only for people wanting to interpret this as RDF
Dave Longley: using graph normalization to compare this regardless of syntax, this can be a prblem
... the skolemization of (certain) bnodes makes the normalization complex
David Booth: Yes, the normalization algorithm may need to know about the well-known IRI suffixes.
Sandro Hawke: a gen-id is not a blank node. it's complex and annoying, but useful.