JSON-LD Community Group Telecon

Minutes for 2011-09-20

Manu Sporny
Markus Lanthaler
Markus Lanthaler, Manu Sporny, Niklas Lindström, Alexandre Passant, Ted Thibodeau Jr., David I. Lehn, Dave Longley
Audio Log
Markus Lanthaler is scribing.
Manu Sporny: Markus, do you have a specific use case for @language in @context? Is it something that you absolutely need?
Markus Lanthaler: Not really, no. I see it as a feature that makes sense, but if we just put it into the @context, that would be enough for almost every use case. If you have different languages, the current approach is fine - don't want it to get too complex.
Manu Sporny: I can see the usefulness of the feature, but I'm concerned that we're adding too many new features to JSON-LD. When we complete the specs, it'll go through a WG, when that happens, we may get even more features. Don't want to have JSON-LD become too complicated. It's the same trap that RDFa fell into. Always more difficult to remove features than add them. Just want to make sure there is an absolute need for the feature before adding it.
Markus Lanthaler: More often, JSON documents are in one language.
Manu Sporny: Most JSON data doesn't have a language associated with it, but I agree.
Niklas Lindström: I need this feature - one language per view in JSON.
Markus Lanthaler: Maybe we support it in @context only for version JSON-LD 1.0.
Niklas Lindström: Let's discuss ordered lists last - Thomas Steiner suggested to postpone discussion/decision on this because of the discussion in the RDFa group.
Manu Sporny: Ok - we'll move that to the end of the Agenda - but we do need to make a decision on it to move this spec forward.

Topic: ISSUE-11: Add support for NULL

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/11
Manu Sporny: I suggest that we not support 'null' right now.
Manu Sporny: people can use rdf:nil for now
Niklas Lindström: rdf:nil means empty list, so not really the same
Niklas Lindström: We could use owl:Nothing.
...perhaps owl:Nothing would describe JSON's null better?
Markus Lanthaler: For some use cases it may be important to support null [scribe assist by Manu Sporny]
Markus Lanthaler: One thing we could do is to define a JSON vocabulary and have a json:null [scribe assist by Manu Sporny]
Markus Lanthaler: That vocabulary is something someone could have for the round-tripping issues for numbers, currently. [scribe assist by Manu Sporny]
Markus Lanthaler: We could just say 'null' is not specified currently. [scribe assist by Manu Sporny]
Niklas Lindström: from an application perspective null means I have no data about it
Niklas Lindström: from graph model it might is the same as not specifying the attribute
Alexandre Passant: I have no preference
PROPOSAL: Leave support for 'null' keyword in JSON-LD as unspecified.
Markus Lanthaler: so what happens if we link a context doc to an existing JSON doc which uses null?
Manu Sporny: if a value has null it's ignored entirely when converting to RDF or normalizing. Perhaps we should be more specific in the proposal?
PROPOSAL: Leave support for 'null' keyword in JSON-LD as unspecified. If a 'null' value is included in a JSON-LD document, it is ignored when converting to the RDF model.
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
Niklas Lindström: .. { "subject": "/niklas#me", "...foaf.../name": null } as RDF = empty graph
Ted Thibodeau Jr.: if it's unspecified it's unspecified, we can't say then that it's ignored when converting
Ted Thibodeau Jr.: unspecified is completely different from ignored
Manu Sporny: should we just leave it completely unspecified, then?
Ted Thibodeau Jr.: Yes
PROPOSAL: Leave support for 'null' keyword in JSON-LD as unspecified.
Markus Lanthaler: What about having json:null?
...This would resolve our round-tripping issues and have a clear mapping to RDF
Manu Sporny: you wouldn't have to show null in normalized documents
Niklas Lindström: http://www.w3.org/TR/rdb-direct-mapping/
Niklas Lindström: problem with rdf:nil is that it's implies that the value is an empty *list*
Ted Thibodeau Jr.: From the RDB spec: "Additionally, the direct mapping does not generate triples for NULL values; note however that it is not known how to relate the behaviour of the obtained RDF graph with the standard SQL semantics of the NULL values of the source RDB. For a detailed discussion of this issue, see a forthcoming working group note."
Ted Thibodeau Jr.: it's an ongoing discussion, no resolution yet.
Niklas Lindström: consider the case where you create data where name = null and then use SPARQL to look for persons where we have no name
Niklas Lindström: what if we want to look for people with no name? What do we query for?
Ted Thibodeau Jr.: null is a very specific "value" which is environment-specific
David I. Lehn: could you use {"@literal":null, "@datatype": "whatever"} to explicitly specify what a null means?
David I. Lehn: not sure if that makes sense at all :)
Manu Sporny: Who is for supporting something like json:null?
David I. Lehn: the issue does mention using "prop": [] to specify no value.. which seems to make sense for some cases
Manu Sporny: would prefer to leave null as unspecified?
Niklas Lindström: http://dbpedia.org/resource/Pointer_%28computing%29%23Null_pointer
Ted Thibodeau Jr.: A quick Google search shows that a lot of people are talking about json:null
PROPOSAL: Create a JSON vocabulary and define json
Manu Sporny: -1 (no compelling use case)
Niklas Lindström: -1
Markus Lanthaler: +1
Ted Thibodeau Jr.: -1
Alexandre Passant: +0 - I think that will overcomplicate things for newbies
PROPOSAL: Leave support for 'null' keyword in JSON-LD as unspecified.
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +0.5 :-)
Niklas Lindström: We could add "@null" in the future if the feature is really needed.
Ted Thibodeau Jr.: +1
Alexandre Passant: +1
David I. Lehn: +1 i think
RESOLUTION: Leave support for 'null' keyword in JSON-LD as unspecified.

Topic: ISSUE-16: Linking instance documents and context documents

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/16
Manu Sporny: what we are trying to do here is to be able to allow people to just continue to publish plain JSON and just add a header to link it to a context
... it would allow to move the context out of the JSON-LD document and into the HTTP response.
... would be an advantage as it would mean people could leave JSON as it is
... however, the downside is that not all people can access HTTP headers
... and there are different places to put a context now.. difficult to know where to look
... question 1 is how are we going to support it?
... it could also just be put in to the API doc but that would prevent machines from discovering it
... I fear that we are putting in too many features, which complicates implementations.
Niklas Lindström: I agree with Manu's reasoning
Niklas Lindström: don't think that anything new will be enabled
Niklas Lindström: should be deferred till a real need comes up
Manu Sporny: If we are forced to do it, I am partial to this: Content-Type: application/ld+json; data=http://www.example.com/context.json
Alexandre Passant: actually, I'd need the Link header for seevl :)
Alexandre Passant: I would prefer to have my JSON to look like plain JSON
Manu Sporny: is the reason to not confuse developers? Has anyone raised this as a concern?
Alexandre Passant: Yes. No one raised the issue yet. Would just like to keep it as simple as possible
Manu Sporny: concern is that a JSON-LD parser might not always has access to link header, which would make the data useless unless you saved the HTTP header along with the JSON-LD document... or modified the JSON-LD document to add the @context.
Alexandre Passant: other reason is compliance with JSON schema
Alexandre Passant: http://json-schema.org/draft-hyperschema.txt
Alexandre Passant: (1.4. Associating instances with schemas.)
Markus Lanthaler: There is an issue with client-side JavaScript implementations... that they can't always get access to the Link header - for example, if the document is loaded via a SCRIPT tag or via JSON-P. [scribe assist by Manu Sporny]
Markus Lanthaler: But that may change in the future. [scribe assist by Manu Sporny]
David I. Lehn: I'm not convinced either way
Ted Thibodeau Jr.: There are issues with Link headers, so we need it in the data
Ted Thibodeau Jr.: but I'm not against as having it as optional
Ted Thibodeau Jr.: but you must have a @context in the document
Ted Thibodeau Jr.: to support JavaScript implementations
Alexandre Passant: yes - the goal is to have "normal" JSON
Manu Sporny: I would be okay with - MUST have it in the JSON-LD document, MAY in Link header
Alexandre Passant: I'd rather "MUST have EITHER in the document or Link header"
Dave Longley: JSON-LD expanded and normalized forms do not have @context at all
Ted Thibodeau Jr.: when @context exists... pointer MUST (or SHOULD?) be in document; MAY additionally be provided in Link header
Manu Sporny: should we push this back to the mailing list?
Alexandre Passant: ok for me
Markus Lanthaler: sure, let's discuss it there