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
Audio Log: audio.ogg

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/main/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