JSON-LD Telecon Minutes for 2011-12-20

The minutes for today's call are now available here:

http://json-ld.org/minutes/2011-12-20/

Full text of the discussion follows:

JSON-LD Community Group Telecon
Minutes for 2011-12-20
Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2011Dec/0043.html
Chair:
   Manu Sporny
Scribe:
   David I. Lehn
Present:
   David I. Lehn, Manu Sporny, Niklas Lindström, Markus Lanthaler

David I. Lehn is scribing.
Manu Sporny:  add to agenda discussion of recent updates
Manu Sporny:  add case sensitivity issue

Topic: Updates to JSON-LD implementations

Manu Sporny:
   http://lists.w3.org/Archives/Public/public-linked-json/2011Dec/0055.html
Manu Sporny: http://json-ld.org/playground/
Manu Sporny:  Dave Longley updated all the implementations based
   on recent decisions. playground updated.
Manu Sporny:  has context modifications for @id, @type, coerce
   rules
Manu Sporny:  dave said due to less keywords need to do more work
   to figure out what you are dealing with. but it worked out in a
   deterministic way.
Niklas Lindström:  removing vocob had some issues. added 30% size
   to context.
Niklas Lindström:  vocab removed, needed to generate context from
   schema with many terms. added heuristics for conversion. used
   experimental features to get data to be datatype coerced or
   multiple object properties.
Manu Sporny:  getting rid of vocab didn't have a negative effect?
Niklas Lindström:  Yes. Might want to revisit introducing vocab
   in the future. Might be able to remove @id from terms. Ivan did
   JSON-LD output from RDFa 1.1 extractor. Everything there could be
   represented with this changes apart from vocab.

Topic: Case sensitivity in JSON-LD

Markus Lanthaler:
   https://github.com/json-ld/json-ld.org/issues/45
Markus Lanthaler:  issue is various keywords (type, id, etc) as
   case sensitive or not. feedback on mailing list was for case
   sensitive. everyone seems to agree now.
PROPOSAL:  JSON-LD is case-sensitive.

David I. Lehn: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
RESOLUTION:  JSON-LD is case-sensitive.


Topic: ISSUE-16: Linking Instance Documents and Context Documents

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/16
Markus Lanthaler:  http has header parms for link headers and
   mime type params. could use this for data or context documents.
Markus Lanthaler:  currently not supported, not clear if it is
   needed
Markus Lanthaler:  may want to link to context document for plain
   json documents
Markus Lanthaler:  issue with breaking json clients due to mime
   type changes to ld+json
Manu Sporny:  against out-of-band data. helpful, but may not use
   it.
Manu Sporny:  more comfortable with link header than changing
   mime type with content type
Manu Sporny:  not sure if content type is required. may want to
   make that a SHOULD vs MUST to deal with client handling issue.
Manu Sporny:  where should this processing happen? should it be
   at application layer? application can look at header and perform
   context retrieval and insertion into document.
Markus Lanthaler:  should look at traditional json documents and
   json-ld docs
Markus Lanthaler:  might not know how to handle docs without
   mimetype hints
Manu Sporny:  think should leave at application level more likely
   to have access to http headers
Markus Lanthaler:  shouldn't require json-ld processors to look
   at headers.
Manu Sporny:  another issue is if rel="describedby" is the proper
   value
Markus Lanthaler:
   http://www.iana.org/assignments/link-relations/link-relations.xml
Markus Lanthaler: describedby: "Refers to a resource providing
   information about the link's context."
Niklas Lindström:  could be put in a "publishing json-ld"
   section. give optional mechanism and advice to users.
Niklas Lindström:  still want to use json mime type but may want
   to add semantic context via http headers
Manu Sporny:  described by looks like proper relation
PROPOSAL:  Support the use of the HTTP "Link" header to associate
   a JSON-LD context with JSON documents.

Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +1
RESOLUTION:  Support the use of the HTTP "Link" header to
   associate a JSON-LD context with JSON documents.

David I. Lehn:  does describedby conflict with other uses?
Markus Lanthaler: Link: <http://www.example.com/context.jsonld>;
   rel="describedby"; type="application/ld+json";
Markus Lanthaler:  due to mimetype uses it should be ok
Markus Lanthaler: no
PROPOSAL:  The relation name used in a Link header to associate a
   JSON-LD context with a JSON document will be "describedby".

Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: +1
David I. Lehn: +1
RESOLUTION:  The relation name used in a Link header to associate
   a JSON-LD context with a JSON document will be "describedby".

Niklas Lindström: .. regarding describedby and json schema, look
   at section for of:
   http://tools.ietf.org/html/draft-zyp-json-schema-03
Niklas Lindström: .. they recommend one of two approaches: "A
   MIME type parameter named "profile" or a relation of
   "describedby" (which could be defined by a Link header)"
David I. Lehn:  what happens if you have context in document and
   a header link?
PROPOSAL:  A JSON-LD document MUST NOT be published with a Link
   header using the "describedby" publishing pattern.

PROPOSAL:  A JSON-LD document SHOULD NOT be published with a Link
   header using the "describedby" publishing pattern.

PROPOSAL:  A JSON-LD document MUST have all context information
   required for processing within the body of the document.

Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
David I. Lehn: +1
RESOLUTION:  A JSON-LD document MUST have all context information
   required for processing within the body of the document.

David I. Lehn:  how to resolve multiple contexts issue?
Manu Sporny:  if json-ld then use context in doc, ignore header.
Manu Sporny:  if json, then use context in doc if found else use
   header info

Topic: ISSUE-41: IRI expansion within @context

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/41
Markus Lanthaler: Greggs email to this issue:
   http://lists.w3.org/Archives/Public/public-linked-json/2011Dec/0049.html
Manu Sporny:  previously didn't want a multi-pass algorithm.
   moving towards multi-pass
Manu Sporny:  will allow definition of, say, xsd in the context
   to describe other keys in the same context
Manu Sporny:  latest implementations support prefixes used
   everywhere. issue making sure not to define http
Markus Lanthaler:  looks supported already. may have issues with
   recursion.
PROPOSAL:  IRI expansion should work in @context for prefixes
   used on the right-hand side of prefix declarations, including
   @type and @id.

Markus Lanthaler: playground also supports terms on the
   right-hand side: http://bit.ly/suonUG
Markus Lanthaler: look at dateTime
Niklas Lindström: .. we should support: {"title": "dc:title",
   "dc": "http://purl.org/dc/terms/"} but not: {"title": "dc:title",
   "dc": "base:terms/", "base": "http://purl.org/dc/"}
   ... discusion on proposal .. multi pass to handle terms and
   prefixes
Niklas Lindström:  this example could require recusrive algorithm
Manu Sporny:  current js code in playground only does one level,
   not recursive
Markus Lanthaler: dirty PHP code supporting the recursive
   expansion:
   https://github.com/lanthaler/JSON-LD-experiments/blob/master/context-coerce-merge.php
Niklas Lindström: .. as long as I can use: {"created": {"@iri":
   "dc:created", "@type": "xsd:date"}, "dc":
   "http://purl.org/dc/terms/", "xsd:" "http://...#"} I'm happy.
Manu Sporny:  may be denial of service attack due to recursion
can be solved with limits
back and forth discussion on recursion issues and resolving
   prefixes.  recursive algorithm may be more flexible and easier to
   teach.  issues with complexity and may require cycle limits.
PROPOSAL:  IRI expansion should work in @context for prefixes
   used on the right-hand side of prefix declarations, including
   @type and @id. The IRI expansion algorithm SHOULD be recursive,
   in that it continues to execute as long as one prefix is expanded
   in the current cycle. If a cycle is detected during resolution,
   then an exception MUST be thrown.

Niklas Lindström: +1
Manu Sporny: +1
David I. Lehn: +1
Markus Lanthaler: +1
David I. Lehn:  (i'd like more input from dave and/or gregg on
   this)
Markus Lanthaler: In JSON-LD, a context is used to map terms,
   i.e., keys and values in an JSON document, to IRIs. A term is a
   short word that may be expanded to an IRI.
Markus Lanthaler: ...
Niklas Lindström: … {"created": {"@iri": "dc:created", "@type":
   "date"}, "dc": "http://purl.org/dc/terms/", "date": "xsd:date",
   "xsd:" "http://...#"} ?
s/@iri/@id/! :)
RESOLUTION:  IRI expansion should work in @context for prefixes
   and terms used on the right-hand side of prefix/term
   declarations, including @type and @id. The IRI expansion
   algorithm SHOULD be recursive, in that it continues to execute as
   long as one prefix/term is expanded in the current cycle. If a
   cycle is detected during resolution, then an exception MUST be
   thrown.

Markus Lanthaler: +1
Niklas Lindström: +1

Topic: ISSUE-43: Use of IRIs and CURIEs as @context keys

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/43
PROPOSAL:  Allow IRI expansion to operate in @context for
   prefixes on the left-hand side of prefix declarations. The IRI
   expansion mechanism SHOULD be recursive, in that it continues to
   execute as long as one prefix/term is expanded in the current
   cycle. If a cycle is detected during resolution, then an
   exception MUST be thrown.

Manu Sporny: +1
Niklas Lindström: +1
Niklas Lindström: … {"foaf:birthday": {"@coerce": "xsd:date"}}
   sort of becomes {"foaf:birthday": {@id: "foaf:birthday",
   @coerce": "xsd:date"}}
Niklas Lindström: … (provided that foaf is already defined)
David I. Lehn:  (gregg had a comment on this issue too)
discussion on tricky details of the issue.
postpone ISSUE-43 to mailing list and later discussion
next telecon Jan 10, 2012


-dave

Received on Tuesday, 20 December 2011 19:41:54 UTC