JSON-LD Community Group Telecon

Minutes for 2012-01-17

Agenda
http://lists.w3.org/Archives/Public/public-linked-json/2012Jan/0016.html
Chair
Manu Sporny
Scribe
Markus Lanthaler
Present
Markus Lanthaler, Manu Sporny, Niklas Lindström, David I. Lehn
Audio Log
audio.ogg
Markus Lanthaler is scribing.

Topic: Plan to finish documents

Manu Sporny: http://lists.w3.org/Archives/Public/public-linked-json/2012Jan/0020.html
Manu Sporny: what we try to achieve is to finish all docs by May and start a WG afterwards
Markus Lanthaler: Other concern was that most people just read syntax spec w/o looking at API spec... there is not enough information in syntax spec to understand how this stuff works w/o reading the API spec. [scribe assist by Manu Sporny]
Markus Lanthaler: We should modularize more - make syntax independent of API spec. [scribe assist by Manu Sporny]
Manu Sporny: I agree with you in principle
Manu Sporny: what do we need to bring over to the syntax spec?
Markus Lanthaler: There are details that are just described in API spec, must move those details over. [scribe assist by Manu Sporny]
Manu Sporny: So, stuff like the expansion and compaction algorithms...
Manu Sporny: I don't know if not having algorithms in syntax spec is enough. [scribe assist by Manu Sporny]
Niklas Lindström: Let's look at some other specs, like the XML spec, to see how they do it
Manu Sporny: We could also look at the JSON spec and separately the JSON.parse() API spec
Niklas Lindström: the compacted and expanded forms could, as Markus said, probably be described in an algorithm-free way
Niklas Lindström: at least the expanded form is possible to describe such as canonical XML
Manu Sporny: so the approach would be to describe that in an algorithm-free way if we can, but specifying the algorithm for expanding values in a JSON-LD document given a @context wouldn't be terrible either.
PROPOSAL: Decouple the JSON-LD Syntax specification from the JSON-LD API specification.
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
David I. Lehn: +1
RESOLUTION: Decouple the JSON-LD Syntax specification from the JSON-LD API specification.
Markus Lanthaler: Manu, what are you thoughts on which W3C group should take that to REC?
Manu Sporny: The RDF working group still has the JSON serialization work on their charter, but we might end up creating a completely new JSON-LD WG... we don't know yet, we need to have that discussion with W3C.

Topic: ISSUE-43: Use of IRIs and CURIEs as @context keys

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/43
Markus Lanthaler: We have a technical issue that is of concern where an @id specified in a CURIE contained in the context, like "foaf:name": {"@id": "http://myotherfoaf.com/name" would override the IRI for FOAF. [scribe assist by Manu Sporny]
Manu Sporny: We could make it so that overriding is okay... [scribe assist by Manu Sporny]
Markus Lanthaler: We could make it such that a direct comparison is done first... so check for "foaf:name" in @context first... and if that exists, use the @id from that value. If no such value exists, look for "foaf" and perform normal CURIE expansion. [scribe assist by Manu Sporny]
PROPOSAL: When expanding JSON-LD keys outside of the @context, perform a direct comparison on the @context keys first, then run the CURIE expansion algorithm using the @context keys.
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
David I. Lehn: +1
RESOLUTION: When expanding JSON-LD keys outside of the @context, perform a direct comparison on the @context keys first, then run the CURIE expansion algorithm using the @context keys.
Manu Sporny: What happens when an @id does not exist in the CURIE in the @context? We could just fall back to regular CURIE expansion.
Niklas Lindström: Why should we allow this? "foaf:name": {"@id": "not-foaf-name"}
Markus Lanthaler: I see it more as *not disallow* it than *allow it*
Niklas Lindström: ok.. we should add a note to not encourage this
Manu Sporny: Yes, this is a corner case and you should only use this type of feature if it's absolutely necessary.
Niklas Lindström: It would make the JSON-LD document very difficult to read.
PROPOSAL: If a CURIE as a key in the @context is not bound to an @id, the @id is determined by expanding the key as a CURIE.
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0
David I. Lehn: Don't we need a set of test cases before resolving something like this?
David I. Lehn: No, typically we design first and then create a test suite once we're sure that the design is sound. A good test suite will catch any technical issues, but I don't think we have any with this approach. Typically, people catch issues like this before a test suite would.
RESOLUTION: If a CURIE as a key in the @context is not bound to an @id, the @id is determined by expanding the key as a CURIE.
Markus Lanthaler: How does @type coercion work? [scribe assist by Manu Sporny]
Markus Lanthaler: In the context you have "foaf" and "foaf:name" (both specify a @type), and in the document you use the full IRI "http://xmlns.com/foaf/0.1/name" - which @type do you use? [scribe assist by Manu Sporny]
Manu Sporny: If you want type coercion to work w/ a full IRI in the data, you must use the full IRI in the @context to specify the @type [scribe assist by Manu Sporny]
Niklas Lindström: Gregg and Ivan needed that for RDF->JSON-LD conversion
PROPOSAL: The type coercion algorithm only checks for equality in the @context keys when attempting to find a type coercion rule.
Markus Lanthaler: +1
Manu Sporny: +1
Niklas Lindström: +1
David I. Lehn: +0
RESOLUTION: The type coercion algorithm only checks for equality in the context when attempting to find a type coercion rule.

Topic: ISSUE-44: Allow frames to say: "predicate p always points to a set"

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/44
Manu Sporny: the problem with this proposal is that there is a conflict with what framing does
Niklas Lindström: More discussion on this: http://lists.w3.org/Archives/Public/public-linked-json/2011Dec/0005.html
Manu Sporny: what we might want to do is to introduce a new keyword such as @structure or @container (as Niklas proposed)
Niklas Lindström: My use case is regardless of framing
Niklas Lindström: In my particular application I don't need framing
Niklas Lindström: I always know the root
Niklas Lindström: That's why I also proposed @rev, but that's another discussion
Niklas Lindström: I need something specifying that something is always an array even if there's just one value
Manu Sporny: why do you need a keyword for that? You could just generate it and tell the people that use your data that the value will always be an array?
Niklas Lindström: I use the context to "specify" this, the @context is a contract of what the data should look like
Manu Sporny: you propose to add a @container that could have to values: @set and @list
Manu Sporny: What we're proposing here are basically document conformance rules. If you use @set or @list, the data MUST always be enclosed in a JSON array structure.
Manu Sporny: the issue I have is that it is a very strange document conformance rule, one that if people don't follow, there isn't really any issue... we could throw an exception if something is marked as a @set or @list, but isn't in a JSON array.
Manu Sporny: If we don't, people could just ignore the rule - the only way to catch that would be to have a JSON-LD document validator or have the processor blow up when it hits something that is supposed to be in a JSON array that isn't.
Niklas Lindström: I see what you mean
Niklas Lindström: if we are going to create a validator we might also wanna have container: object for single values
PROPOSAL: Add the @container keyword to JSON-LD and allow it's value to be '@list' to specify that values MUST be interpreted as a RDF List.
Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: Would that imply that every property has to be an array even if there's just a simple value
Niklas Lindström: Yes, but that's what @list does as well at the moment, right?
Markus Lanthaler: no.. @list just says that if it is an array, the order has to be preserved
Niklas Lindström: only every property with @container defined in the context (or currently @list)
Markus Lanthaler: That's what I meant :-)
Niklas Lindström: Good. :) I figured it was, just wanted to make sure.
Manu Sporny: Ok, well - let's kick this discussion back to the mailing list. I prefer that we use '@container': '@list' instead of '@list': 'true' because that allows us to add '@set' in the future in a clean way. Good call, we'll chat next week.