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.

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.

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

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?

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

Markus Lanthaler: What about having json:null?

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

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

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

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

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