JSON-LD Telecon Minutes for 2011-10-04

Many thanks to Henri for scribing! The minutes for today's call are now
available here:

http://json-ld.org/minutes/2011-10-04/

Full text of the discussion follows, as well as a link to the complete
audio transcript:

JSON-LD Community Group Telecon Minutes for 2011-10-04
Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2011Oct/0010.html
Chair:
   Manu Sporny
Scribe:
   Henri Bergius
Present:
   Niklas Lindström, Manu Sporny, Henri Bergius, Gregg Kellogg, Ted
   Thibodeau Jr., Alexandre Passant, Markus Lanthaler, David I. Lehn
Audio:
   http://json-ld.org/minutes/2011-10-04/audio.ogg

Niklas Lindström:  Maybe we want to do Agendum #3 and then #2
   because of the dependency? [scribe assist by Manu Sporny]
Manu Sporny:  Yes, let's swap those two. [scribe assist by Manu
   Sporny]
Henri Bergius:  Talked with Web Intents people at JSConf - had
   some ideas that it would be interesting to pass JSON-LD through
   Web Intents. [scribe assist by Manu Sporny]
Manu Sporny:  Can you do a quick introduction to the topic on the
   mailing list first, Henri? Then we could add it as an issue and
   discuss in more detail on the call? [scribe assist by Manu
   Sporny]
Henri Bergius:  Ok, I'll do that. [scribe assist by Manu Sporny]
Henri Bergius is scribing.

Topic: ISSUE-12: Arrays as ordered lists or unordered sets

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/12
Manu Sporny:  This issue concerns how JSON-LD expresses ordered
   lists, at the moment we only have unordered sets
Manu Sporny:  ordering is useful for playlists, payments etc
Gregg Kellogg:  proposed @list keyword with array, expressing
   that the array ought to be ordered.
Manu Sporny: +1 for supporting ordered lists, I think we can do
   it in a nice, clean way in JSON-LD.
Markus Lanthaler: +1 to support it
Manu Sporny:  coming around to supporting ordering lists,
   traditionally didn't like it in RDFa but now there is a new
   syntax that is nice to use.
Manu Sporny:  Microdata has ordered lists, so if we want to
   express Microdata cleanly in JSON-LD, we need ordered lists
Niklas Lindström:  I like the format proposed by Gregg
Niklas Lindström:  Lists should be explicitly added. How could a
   reference always be treated as a list? I need to solve this
   issue. Example:
Niklas Lindström:
   http://service.demo.lagrummet.se/json-ld/context.json
Manu Sporny:  framing could possibly be used for addressing the
   use case of always treating something as a list or a set. I don't
   think we need to solve it via @coerce.
Manu Sporny:  both coercion and expanded forms for lists are
   needed, otherwise lists can't be normalized. Should we consider
   ordered lists are the default since this is what it means in
   JSON?
Ted Thibodeau Jr.: ordered by default? that seems problematic.
Manu Sporny:  considering JSON-LD arrays to be ordered would make
   RDF mapping very complicated.
Markus Lanthaler: -1
Manu Sporny: -1
David I. Lehn: -1
Niklas Lindström: -1
Henri Bergius: -1
Gregg Kellogg: -1
Ted Thibodeau Jr.: -1
Alexandre Passant: 0
Manu Sporny:  anybody having problems with the @list keyword in
   both document body and coercion rules?
Markus Lanthaler: I have no problem with it
PROPOSAL:  Support @list keyword in @coerce as well as in
   expanded form in the body of JSON-LD documents.

Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Henri Bergius: +1
Markus Lanthaler: +1
Ted Thibodeau Jr.: +1
Alexandre Passant: +1
David I. Lehn: +0 i guess. i haven't really used it enough to
   vote.
RESOLUTION:  Support @list keyword in @coerce as well as in
   expanded form in the body of JSON-LD documents.

Markus Lanthaler: Shall we introduce a mechanism to change the
   default (i.e. how arrays are interpreted) as well?
Gregg Kellogg:  making list handling changeable would make
   processing modal and complicated
Markus Lanthaler: Not really at this point
Manu Sporny:  in current framing you can tell an item to always
   be an array, for instance
Niklas Lindström:  also finding more cases where framing is
   needed
PROPOSAL:  Support the @set keyword to specify that a property is
   a set and not an ordered list.

Manu Sporny: -1
Gregg Kellogg: -1
Niklas Lindström: -1
Markus Lanthaler: -1 if we consider arrays as unordered by
   default there's no need for a set keyword
Henri Bergius: -1
David I. Lehn: -1
Ted Thibodeau Jr.: -1
Manu Sporny:  we have now arrays and ordered lists, @list can be
   used both in body and coercion. Anything else to discuss on lists
   before we move on?

Topic: ISSUE-30: Distinguishing @context documents

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/30
Manu Sporny:  There are three different ways to distinguish
   context documents that have been proposed: MIME type (considered
   overkill), MIME type param (form=context, hard for web server to
   determine without file extension), including @context in pure
   context docs
Manu Sporny:  if you specify an external context in your
   @context, the JSON-LD processor would fetch that external
   document and look for @context there
Niklas Lindström:  would an embedded context also have @context
   string?
Manu Sporny: "@context": ["http://example.com/mycontext.jsonld",
   {"foo": "http://foo.org/foo#"}]
Manu Sporny:  JSON-LD processor should load external context
   document first, then overlay local context items into that in
   order of when they are specified in the @context array (if it is
   an array)
Manu Sporny: This is the regular JSON-LD document: "@context":
   ["http://example.com/mycontext.jsonld", {"foo":
   "http://foo.org/foo#"}]
Manu Sporny: This is the context JSON-LD document
   ("http://example.com/mycontext.jsonld"): "@context":
   ["http://thiswouldnotload.example.com/othercontext.jsonld",
   {"bar": "http://bar.org/bar#"}]
Manu Sporny: The final context would be: {"bar":
   "http://bar.org/bar#", "foo": "http://foo.org/foo#"} because the
   remote document in the context document would fail to be loaded.
Niklas Lindström: {"@context": {"@context":
   "http://example.org/mycontext.jsonld", "@language": "sv"}, ... }
Manu Sporny:  you can't embed a remote context inside a context,
   but the example above would load mycontext.jsonld and then
   overlay @language "sv" on top of that.
Niklas Lindström: {"@context":
   ["http://example.org/mycontext.jsonld", {"@language": "sv"}], ...
   }
Gregg Kellogg:  context inside a context is a problem for
   processing and would need extra code. It's easier to just ignore
   that value.
Markus Lanthaler: I agree with Gregg. I wouldn't like to have
   that "don't follow links in context documents" rule in the spec.
Niklas Lindström:  using @context in a context document would
   still make it look like an instance document
Manu Sporny:  there is no difference between a context doc and an
   instance doc
David I. Lehn: There is probably some overlap in functionality
   between external @context issues and a generic @import syntax.
   probably want to pick some syntax that would work for a future
   @import extension. That may imply using the @context inside the
   context doc
Markus Lanthaler: yes, me
Markus Lanthaler: is there really a recursion issue?
Niklas Lindström:  proposal: rule to prevent fetching same URL
   twice to protect against loops
Manu Sporny:  recursion could also stop at a given recursion
   level
Manu Sporny:  DDOS could be possible by referencing lots of
   documents in @context, or you could just refer to one context
   document, which refers to 2 documents, which refers to 3
   documents, etc. There are lots of DDOS issues when loading
   external documents.
Niklas Lindström:  it might be useful to include some base
   context in external contexts
Manu Sporny:  DDOS and other attacks come up when discussing
   browser technologies etc. It's important to talk about these
   attacks.
Manu Sporny:  there have been proposals to have hardcoded
   prefixes etc to prevent fetching of external resources for RDFa
   Profiles (when that feature existed in RDFa 1.1).
Manu Sporny:  possibly processors should be limited to X lookups
   per JSON-LD @context?
David I. Lehn: so many complex issues come up for such a simple
   feature!
Markus Lanthaler: exactly, we should warn about the potential
   misuse in the spec and that's it
Niklas Lindström: +1 to document recursion/DDOS risks in the spec
   (and perhaps SHOULD on limits)
Niklas Lindström: something like "a processor MAY stop at depth 4
   or when it has loaded more than 10 contexts"...
Manu Sporny:  when dereferencing an external context, the JSON-LD
   processor expects a @context keyword to be available on toplevel
Gregg Kellogg:  Could JSON-LD processor ignore everything else
   than context when referring to external context
Manu Sporny:  Yes. Keep in mind that external @context documents
   could be self-expressing - they could have creation date, author
   information, etc. This information MUST NOT be imported into the
   default graph of a JSON-LD processor.
Niklas Lindström:  there is benefit in self-describing
   information, but we should limit it to prevent copy-pasting
Manu Sporny:  context documents will be downloaded many many
   times, so they probably should be lean - but we shouldn't be
   heavy-handed about what can go inside of a @context document if
   it's just another JSON-LD document.
PROPOSAL:  Do not differentiate between JSON-LD Context documents
   and JSON-LD instance documents - there are just JSON-LD
   documents.

Markus Lanthaler:  if we retrieve a JSON-LD document when
   processing @context, we discard all data that is not in the
   context.
Manu Sporny:  we need to figure out a way to explain this in the
   spec, to say whether to ignore triples from context, or to put
   them into the processor graph
Manu Sporny:  Merging data from external JSON-LD documents is ...
   iffy
Manu Sporny:  there is definitely a difference between JSON-LD
   documents and context documents. Syntax is same, but contents are
   treated differently
PROPOSAL:  Do not differentiate between JSON-LD Context documents
   and JSON-LD instance documents. If @context is specified and a
   remote document is listed, the remote document SHOULD have a
   @context key in the top level JSON object.

Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +1
Henri Bergius: +1
Niklas Lindström: +1
Ted Thibodeau Jr.: +0
Alexandre Passant: +1
Ted Thibodeau Jr.:  why does a document that has been referenced
   as a @context needs a @context?
Manu Sporny:  this way authors only have a single set of rules
   for authoring JSON-LD documents. Previously, the way you authored
   JSON-LD Context documents was different from JSON-LD Instance
   documents. Now, the authoring rules are the same for both types
   of documents.
Ted Thibodeau Jr.:  there is no reason for the remote context
   document to have a context. If it has one, then the processor
   could follow an external link in that context as well.
David I. Lehn: I think there is something odd about this too. Not
   quite sure how to explain it right now though.
Manu Sporny:  the question is whether to look at top-level
   properties of the external context document, or to look at
   properties inside the @context key of the external context
   document. Most of the people on the call seem to have decided to
   do the latter.
Manu Sporny:  proposal - can we wrap it up now as there are many
   +1s. The issue can be reopened later if it seems as if there is a
   problem with it.
David I. Lehn: What happens if the remote doc doesn't have
   @context in it?
Manu Sporny: Then the @context isn't modified and processing
   continues. It effectively ignores the remote document.
Markus Lanthaler: It says import the @context element in the
   remote JSON-LD in the current document and merge it with the
   local context
Niklas Lindström: Given: data =
   json.parse(urlopen("http://example.org/mycontext.jsonld")) --
   Before this change: context = data -- After: context =
   data['@context']
Markus Lanthaler: Exactly, you don't have to distinguish between
   them because there will just be JSON-LD documents... as a
   consequence we do not need different MIME types
Gregg Kellogg: q
Niklas Lindström: If a @context value is a string, treat it as a
   URL, dereference and import any context defined there
Manu Sporny:  We're out of time for today, we should move this
   back to mailing list and get a more solid proposal done there...
   and discuss again on the next telco.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
Standardizing Payment Links
http://manu.sporny.org/2011/payment-links/

Received on Tuesday, 4 October 2011 17:44:38 UTC