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.

Manu Sporny: +1

Markus Lanthaler: +1

Niklas Lindström: +1

David I. Lehn: +1

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.

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]

Manu Sporny: +1

Markus Lanthaler: +1

Niklas Lindström: +1

David I. Lehn: +1

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.

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.

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

Markus Lanthaler: +1

Manu Sporny: +1

Niklas Lindström: +1

David I. Lehn: +0

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

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.