JSON for Linking Data Telecon Minutes for 2011-09-20

JSON-LD Community Group Telecon Minutes for 2011-09-20

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2011Sep/0097.html
Chair:
   Manu Sporny
Scribe:
   Markus Lanthaler
Present:
   Markus Lanthaler, Manu Sporny, Niklas Lindström, Alexandre
   Passant, Ted Thibodeau Jr., David I. Lehn, Dave Longley

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

Received on Tuesday, 20 September 2011 18:19:31 UTC