JSON-LD Community Group Telecon

Minutes for 2012-06-12

Agenda
http://lists.w3.org/Archives/Public/public-linked-json/2012Jun/0021.html
Topics
  1. Use of @container to specify language-maps and other useful things
  2. Review latest JSON-LD Syntax and API specs
  3. ISSUE-120: Expand @type to @id-objects
Resolutions
  1. Attempt to add other @container options, such as "@container": "@language" to support Wikidata's language-map use case.
  2. When operating on @type, the result of the expansion algorithm MUST always result in an array of strings that are IRIs.
  3. In the expansion algorithm, when expanding a value associated with @type that is a JSON object, extract only @id from that value. Any value that does not expand to an absolute IRI MUST be discarded.
Chair
Manu Sporny
Scribe
Gregg Kellogg
Present
Manu Sporny, Gregg Kellogg, Niklas Lindström, François Daoust, David I. Lehn
Audio Log
audio.ogg
Manu Sporny: Discussion about Stardog, JSON-LD and the upcoming NoSQL conference.
Gregg Kellogg is scribing.
Niklas Lindström: discussion of @container with @language?

Topic: Use of @container to specify language-maps and other useful things

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/133
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/134
Niklas Lindström: previously, I had brought up something for if the language was a key.
… we've seen some other cases where we'd like like
Gregg Kellogg: Yeah, Wikidata is quite interested in using a JSON expression for their APIs - Wikidata exists to communicate with other Wikis... they're quite interested in JSON-LD [scribe assist by Manu Sporny]
Gregg Kellogg: It would allow them to avoid having a different JSON serialization - they presented some use cases - they'd like to, for some wiki topic, have a way of expressing that topic in JSON-LD. The problem is that they need to be able to express this in many different languages/keys - it's the array-as-object pattern. [scribe assist by Manu Sporny]
Gregg Kellogg: So each key is a subject, not a property... ISSUE-133 would be contain underneath whatever key references it. Wikidata says that they would place the english version or the german version of a video in this layout. [scribe assist by Manu Sporny]
Niklas Lindström: if 133 was chosen, if you have objects, it could be specified in a way so that the expression used, if the object is not a value, the language is set below.
… but, not sure @language works that way.
Gregg Kellogg: My original concern was to add a @context that defines a particular language... from Denny's perspective, he would be perfectly happy if he had to explicitly set a context that defines a language - not really a short-cut to avoid extra description... it's an index pattern which is important. He wants to be able to access this stuff using JavaScript object notation. [scribe assist by Manu Sporny]
Niklas Lindström: we might want to study this pattern for things other than @language (such as @id).
… I have some suspicion that JSON keys are used not as properties, but as "index" keys for values.
… consider RDF/JSON, which has as it's outer container something which works like an indexing feature.
… this pattern is fairly conventional in JSON. I wonder how far towards a transformation language we want to go.
… We can't just do the simplest thing possible, because we need to be able to allow for such usage patterns.
… if we can make it understandable, can we work with @container to adopt more conventional forms of JSON.
Manu Sporny: I have a couple of concerns:
… 1) is denny modeling his data that makes sense for JSON-LD?
… we've already said there are patterns we're not going to support.
… I'm concerned about the overhead it adds, not to processing, but to the intellectual overhead.
… Same issue that WHATWG had with RDFa - that there are too many ways to say the same thing.
Gregg Kellogg: Yes, the main reason Denny wants this is that he wants to be able to access these values in JavaScript dot-notation... [scribe assist by Manu Sporny]
Gregg Kellogg: regarding intellectual complexity - my philosophy on language design is a bit different - simple things should be simple, complex things should be possible (not impossible) [scribe assist by Manu Sporny]
Gregg Kellogg: I think we need to consider this as a fairly standard usage pattern... I'm not convinced we need to support it via compaction/framing, but as a way of being able to express JSON where you can derive RDF, it's interesting. [scribe assist by Manu Sporny]
Niklas Lindström: I appreciate manu's concerns about discussing the usage pattern in-depth, but I think that what gkellogg said may be true, that it is a common usage pattern.
… It may be more predictable to do this by extending @container. Probing makes it more difficult to read the JSON and glean the data.
… Embedding RDF forms in "noisy" JSON may open a can of words.
… I we us @container for @language (and maybe @id) it will make it easier to read.
… It's true that you can no longer rely on a key being a property.
… But the idea, is to stick to existing usage patterns. Given that indexing is a common usage pattern, and is the most expressive and useful, JSON-LD may be marginalized if it can't support this pattern.
… I've seen many templating patterns where being able to use keys in this manner would simplify things.
… If we define it as a mechanism of container, anyone knowing how JSON-LD @context works, will figure this out quickly.
Manu Sporny: I hear general agreement that we're going to try to make it work.
… As markus said, there are still some issues about how this will work.
Niklas Lindström: I experimented with language mapping before, and it worked okay for compaction.
… oddly shaped data will highlight the edge-cases.
… using keys of different types in a language can lead to a conflict, but we can provide a mechanism to resolve this, such as to skip the @container: @language definition.
Manu Sporny: we should probably table for now until we have an implementation.
… once we work out the edge-cases, we should come back to it.
… One concern is that does really affect the syntax, so we can't put it off for too long.
PROPOSAL: Attempt to add other @container options, such as "@container"; "@language" to support Wikidata's language-map use case.
Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
François Daoust: +1
David I. Lehn: +1
RESOLUTION: Attempt to add other @container options, such as "@container": "@language" to support Wikidata's language-map use case.

Topic: Review latest JSON-LD Syntax and API specs

Manu Sporny: http://json-ld.org/spec/latest/json-ld-syntax/
Manu Sporny: http://json-ld.org/spec/latest/json-ld-api/
Manu Sporny: I sent an email out to the RDF WG indicating that we had applied all change requests to the documents, marking it up as an FPWD.
Manu Sporny: http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jun/0028.html
… I linked to each commit to make sure that every piece of feedback was responded to.
… the big changes were that the JSON-LD API now has an introductory section that is specific to it.
… We added issue markers to indicate that it's been in development for 18 months, and scope, and alignment with RDF Concepts.
… Hopefully, they'll look at it tomorrow, they'll publish as an FPWD.
… Hope for FPWD in the month of July.

Topic: ISSUE-120: Expand @type to @id-objects

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/120
Manu Sporny: this has do do with the expanded form of @type. Should it be expanded to {"@id"} form? or should we keep it as is, where it can only be a string or an array of strings.
François Daoust: [I note a missing "API" in the title of the spec in the normative reference to JSON-LD API: http://json-ld.org/spec/latest/json-ld-syntax/#bib-JSON-LD-API ]
Gregg Kellogg: There are two things that drive this - one of them is the IRI space for @type being different than other keys like @id - perhaps it should be kept distinct by not using the @id pattern. If we use the @id pattern, you would be in a different context when you applied that. If you needed vocab expansion, or an absolute IRI vs. relative IRI would need to be thought about more deeply. [scribe assist by Manu Sporny]
Gregg Kellogg: That said, in expansion we should tolerate seeing values of this type which are expressed in the @id form... the canonical form would be to just be an array of strings. [scribe assist by Manu Sporny]
Gregg Kellogg: So, I'm in support of supporting this feature. [scribe assist by Manu Sporny]
Niklas Lindström: I'm pretty sure that I'm in agreement on Gregg on all of this - I have the same perspective. [scribe assist by Manu Sporny]
Niklas Lindström: I'm pretty sure that I agree with Gregg on this stuff. I have the same perspective on the items that are brought up.
… with possible exception to the notion of expansion. If this is the case, we should also change @type to be like rdf:type.
… @type is a syntactical expression, and if we expand it, we should expand to rdf:type.
Gregg Kellogg: I'm worried that we push a bit too much RDF onto the JSON folks if we do that... I'm not too keen on expanding "@type" to "rdf:type" on expansion. [scribe assist by Manu Sporny]
Niklas Lindström: I'm not sure which side I'll end up on.
Manu Sporny: I'm a bit concerned about expanding to rdf:type too. It might be more pure from an RDF standpoint, but we don't want to push this on people that aren't interested in RDF.
… This is a type of confusion we'd like to stay away from.
… Two different things, what happens on RHS and on LHS.
Niklas Lindström: on the LHS, we use @type, the value on the RHS should never be an object.
… If you want to do this in the context, you'd need to be sure when expanding that this wasn't the case.
… I feel that we shouldn't expand @type.
Manu Sporny: I thought we were talking about if the RHS of @type to have an object when expanding.
Manu Sporny: In expansion, should we do this: "@type": "http://xmlns.com/foaf/0.1/Person" or this: "@type": { "@id": "http://xmlns.com/foaf/0.1/Person" }
Gregg Kellogg: yes, that's what this issue is about - if we have foaf:Person - does it expand into the IRI form or the object form? [scribe assist by Manu Sporny]
"type": {"@id": "foaf:Person"}
Gregg Kellogg: There are at least three cases here - what happens when "@type" is aliased to "type", what happens if somebody does "rdf:type" on the LHS, what happens to { "@id": ... } in expanded form [scribe assist by Manu Sporny]
Manu Sporny: to be consistent, we should always express as a string, or expand out into a subject reference.
… it seems to me that for @type we should expand out to the @id form.
… we do that for everything else.
Niklas Lindström: then you'd do it for literals too?
Manu Sporny: if we expanded an object with a label, we'd through the label away.
… we don't do it for @id or @type. If you want to express more information, define it elsewhere.
… @type is no different from @id and the datatype usage. If you want to say more, say more somewhere else.
Niklas Lindström: .. [ {"@id": "a", "@type": {"@id": "http://example.com/type", "label": "Type name"} } ]
Niklas Lindström: my problem is that @type is a specific syntactic form. That's why I brought up that a consistent form is to expand @type tordf:type
Niklas Lindström: [ {"@id": "a" "@type": ["http://example.com/type"]}, {"@id": "http://example.com/type", "label": "Type name"} ]
Gregg Kellogg: This is an interesting artifact - in TURTLE you can't do chaining for objects that are also subjects. [scribe assist by Manu Sporny]
Gregg Kellogg: Niklas' second form is the only way you can express it in TURTLE... [scribe assist by Manu Sporny]
Manu Sporny: consensus that when we have @type with objects, we just take the IRIs and through way the other data when expanding.
Niklas Lindström: .. [ {"@id": "a", "type": {"@id": "http://example.com/type", "label": "Type name"} } ]
Niklas Lindström: want to be sure that in compaction, I can get back to that example.
Niklas Lindström: .. "type": "rdf:type"
PROPOSAL: In expanded form, the value of @type MUST be a string or an array of strings that are IRIs. If expanded form is used to express one or more object references @type (e.g. "@type"
PROPOSAL: In expanded form, the value of @type MUST always be an array of strings that are IRIs.
PROPOSAL: When operating on @type, the result of the expansion algorithm MUST always result in an array of strings that are IRIs.
Gregg Kellogg: +1
Manu Sporny: +1
François Daoust: abstains (proposal sounds good, I just don't feel I get the ins and outs correctly on that issue)
David I. Lehn: +0
Niklas Lindström: +1
RESOLUTION: When operating on @type, the result of the expansion algorithm MUST always result in an array of strings that are IRIs.
Manu Sporny: A clarification on the resolution above. [scribe assist by Manu Sporny]
PROPOSAL: In the expansion algorithm, when expanding the value associated with @type, if a JSON object is detected, only the value of @id MUST be used.
PROPOSAL: when expanding the object value of a key interpreted as @type, extract only @id from that value. Discard any value that does not expand to an absolute IRI.
PROPOSAL: In the expansion algorithm, when expanding a value associated with @type that is a JSON object, extract only @id from that value. Any value that does not expand to an absolute IRI MUST be discarded.
Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
François Daoust: abstains (same comment)
David I. Lehn: +0
RESOLUTION: In the expansion algorithm, when expanding a value associated with @type that is a JSON object, extract only @id from that value. Any value that does not expand to an absolute IRI MUST be discarded.