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]

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

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.

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

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?

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.

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

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.