Niklas Lindström: Regarding the graphify() mechanism, I've been playing around a little with a connect() mechanism here - you guys might be interested in that:

Niklas Lindström: https://github.com/niklasl/rdfa-lab/blob/gh-pages/test/test_ld.js

Niklas Lindström: https://github.com/niklasl/rdfa-lab/blob/gh-pages/test/test_rdf.js

Manu Sporny: Any discussion items to add to the Agenda? [scribe assist by Manu Sporny]

Markus Lanthaler: Yeah, ISSUE-120 - we need to determine what happens when an @id is detected in an object associated with @type. [scribe assist by Manu Sporny]

Manu Sporny: we decided we're not expanding @type to @id objects. The question is if we allow usage of @id objects for @type, or if we should throw exceptions

Gregg Kellogg: were using callbacks more for error; so if we see this usage, we can allow the app to decide what to do.

Gregg Kellogg: I feel it is important to support that pattern, in the case some JSON used the type construct like this, and we want to cast it to @type

Manu Sporny: we should call the callback

Gregg Kellogg: we need to figure out the callback workings; is it an event bubbling kind of mechanism?

Gregg Kellogg: should they propagate etc.

Manu Sporny: yes, we should discuss this more

Gregg Kellogg: also, in a non-programmatic context (distiller etc.), we should do the most liberal thing: i.e. use the @id

Manu Sporny: so we should call the callback (which is it? not error handler...)

Gregg Kellogg: the callback should be able to cancel the use...

Manu Sporny: there might be three choices: use, ignore or stop

Gregg Kellogg: use a binary for use/ignore and throw exception to stop

Markus Lanthaler: +1

Manu Sporny: +1

Gregg Kellogg: +1

Niklas Lindström: +1

Markus Lanthaler: for all cases where there is non-conformant data?

Manu Sporny: To clarify - the handler callback is called whenever any "non-conforming" data is found.

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/114

Manu Sporny: with this mechanism, a document isn't automatically invalid when a document doesn't conform to the grammar. This allows for figuring out what the data should mean.

Gregg Kellogg: if we define what can be handled automatically, the document would be conformant still

Markus Lanthaler: but when is a document clearly non-conformant?

Manu Sporny: we don't want to make the statement that a JSON-LD doc with non-defined terms is non-conformant

Markus Lanthaler: but that is explicitly ignored

Manu Sporny: true. we have to be careful about how we define this

Gregg Kellogg: the reason for having a grammar was that before we had spread out in various places what forms are allowed where

Niklas Lindström: I wonder to what extent we need to keep using the abstract description? There are only a few cases where we need to handle non-canonical expressions. [scribe assist by Manu Sporny]

Niklas Lindström: The specific case is where you are coercing to an @id, but you have an object that is a JavaScript object with an 'id' keyword. [scribe assist by Manu Sporny]

Niklas Lindström: There is also value coercion - we need to call out for that. Maybe we can just define these specific cases? If you coerce to @id and you have an entire object there, the object will be thrown away, but the @id will be kept. [scribe assist by Manu Sporny]

Niklas Lindström: If you have coerced to a literal, you have @id or @language - you will throw an error. If you use an expanded literal for @type, you will throw an error. [scribe assist by Manu Sporny]

Manu Sporny: do we need to express in prose or EBNF?

Gregg Kellogg: I started on EBNF, but that's difficult, and probably not appropriate

Markus Lanthaler: http://json-ld.org/spec/latest/json-ld-syntax/#json-ld-authoring-guidelines

Niklas Lindström: EBNF is not applicable [scribe assist by Manu Sporny]

Markus Lanthaler: https://github.com/json-ld/json-ld.org/issues/114#issuecomment-5820544

Gregg Kellogg: that's a compact, good start. it needs some more work, but it's good and usable

Gregg Kellogg: just prose, highlighted with examples would be good

Manu Sporny: but don't we have lots of that? we need some kind of summary (which Andy looked for)

Gregg Kellogg: we could repeat what we say above [in the spec], but top-down instead of bottom-up

Gregg Kellogg: I'll add a issue feature to respec.js

Manu Sporny: so we'll attempt to express the json-ld grammar (gregg will start on it)

Markus Lanthaler: in prose, right?

Manu Sporny: yes, but possibly with formal tables etc.

Gregg Kellogg: a processor must note when a document is non-conformant, but may still produce data

Gregg Kellogg: +1

Manu Sporny: +1

Markus Lanthaler: +1

Niklas Lindström: +1

Niklas Lindström: We need to outline all the things that are problematic - for example, using @graph in @context. [scribe assist by Manu Sporny]

Manu Sporny: we may have to leave certain deviations undefined

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/142

Manu Sporny: brought up for the drupal use case

Manu Sporny: the biggest question is do we want to support this?

Niklas Lindström: I thought about this before this was brought up - it's similar to RDFa... I think in our situation, it does complicate things. [scribe assist by Manu Sporny]

Niklas Lindström: It's one thing to use this when you are interpreting compact JSON... so that when you're expanding it, you have more than one triple for each key. [scribe assist by Manu Sporny]

Niklas Lindström: Compacting data is much harder - if you use a context with these kinds of terms, we have to say something more specific - it's a sort of inference... data will magically appear that doesn't exist in the input. [scribe assist by Manu Sporny]

Niklas Lindström: Something that would be much more complex, but proper - a term should only match when all items are in the document. [scribe assist by Manu Sporny]

Gregg Kellogg: for expressing data, this is quite useful. But my opinion is also that we've painted ourselves into a corner when it comes to compacting data with contexts using these

Gregg Kellogg: I can see for expressing data, this is very useful. My opinion though, is that we've painted ourselves into a corner when we do compaction. There are other examples where we output things that are non-intuitive because we are strictly adhering to the @context expression. If you have something that's not a date that is a term. [scribe assist by Manu Sporny]

Gregg Kellogg: we may have to separate these concepts from the task of compaction

Gregg Kellogg: so that we can use these forms to *express* data but not apply them when compacting

Stéphane Corlosquet: can a feature be supported for one way (expansion) and not the other way (compaction)?

Markus Lanthaler: is that feature really required? in restful apis, you can use e.g. content negotiation for different uses

Manu Sporny: scor, that's what we're discussing right now - we /could/ do it... but it would be the first time we're doing something like that.

Stéphane Corlosquet: other formats, like RDFa and microdata, support this feature.

Stéphane Corlosquet: and we use this in Drupal, so we'd have to do something special for JSON-LD if we don't have this

Stéphane Corlosquet: it's gonna be more verbose

Gregg Kellogg: a possible consequence of this would be to allow key-object keys to have a space-separated list of terms

Gregg Kellogg: {"schema:name dc:title": "foo"}

Manu Sporny: I'm concerned that it's too foreign for JSON developers. It's a neat trick, but it would be hard to use that data

Niklas Lindström: I probably agree

Gregg Kellogg: {"@context": { "term": {"@id": ["dc:title", "schema:name", "foaf:name"]}}}

Markus Lanthaler: the other question is: who are the clients of these documents?

Stéphane Corlosquet: there is a proposal in the drupal community, and to define a local namespace for properties, which would be used for sharing data. At the same time, we want to support schema.org, DC, etc.

Markus Lanthaler: What about data.jsonld?vocab=foaf vs. data.jsonld?vocab=schema

Stéphane Corlosquet: conneg for this is not a mature pattern which is commonly used by clients

Manu Sporny: Markus, I think the issue is that they don't have to do that anywhere else in their system.

Stéphane Corlosquet: different consumers understand different parts, and we want to target as many as possible with the same data.

Markus Lanthaler: I see your point

Manu Sporny: the pattern among linked data publishers right now; JSON-LD is used by e.g. VIE in the backend, and the JSON-LD is transformed to RDFa, and then lifted out again.

Manu Sporny: they wanted to use multiple vocabularies, so this would be usable. If we can figure out the issue with compaction...

Gregg Kellogg: another approach would be to use vocabulary expansion..

Niklas Lindström: I think that it would be easier to use this feature than something like an "RDFa Profile"... this is a more raw equivalent of that. [scribe assist by Manu Sporny]

Niklas Lindström: The more RDF-y the Web gets, the easier all of this gets... we would ultimately use our own vocabs w/ mappings. [scribe assist by Manu Sporny]

Niklas Lindström: But that's 5-10 years off. [scribe assist by Manu Sporny]

Gregg Kellogg: we could support this, but not apply it on compaction

Manu Sporny: we should determine if we need this, and then if it should or shouldn't apply in compaction

Stéphane Corlosquet: "@context": {

Stéphane Corlosquet: "name": "http://xmlns.com/foaf/0.1/name http://schema.org/name",

Gregg Kellogg: {"@context": { "term": {"@id": ["dc:title", "schema:name", "foaf:name"]}}}

Gregg Kellogg: {"@context": {"term": ["dc:title", "schema:name"]}}

Manu Sporny: +1

Gregg Kellogg: +1

Stéphane Corlosquet: +1

Markus Lanthaler: +0.5

Niklas Lindström: +1 (provided we can solve how to handle it in compaction)

Manu Sporny: What is this compacted to? { "dc:title": "title1", "schema:name": "title2" }

Niklas Lindström: re: compaction w/ single-to-multiple terms - three ways to solve this - if any @id matches use that term, match only if all items match, only use first term in the list. [scribe assist by Manu Sporny]

Markus Lanthaler: What is this compacted to? { "dc:title": "sametitle", "schema:name": "sametitle" }

Manu Sporny: mlnt, don't you mean this - { "dc:title": "sametitle", "schema:title": "sametitle" } ?

Manu Sporny: that's the second case, I was also wondering what happens if you have two different values [scribe assist by Markus Lanthaler]

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/144

Manu Sporny: I have a severe reaction to this… [ ;) ]

Manu Sporny: this suggests that a term can mean different things depending on where in the data it appears, depending on terms referencing the current piece

Manu Sporny: we already support this by explicitly using "@context" at various places

Niklas Lindström: I have explored this idea before... it's way too complex. There is a nice academic idea that you could adapt to almost any data... but it gets very complex to process and much harder to read the data. [scribe assist by Manu Sporny]

Niklas Lindström: If you mix-match terms in the same document, such that you can't use the same term for the same meaning, you're in trouble... it's a bad practice. [scribe assist by Manu Sporny]

Niklas Lindström: We already support this via @context embedding... [scribe assist by Manu Sporny]

Gregg Kellogg: I'm with niklas

Niklas Lindström: You could take the approach where you bind a @context to a type... but I still think it's too much... I'm not in support of it at this point. [scribe assist by Manu Sporny]

Markus Lanthaler: +1

Manu Sporny: +1

Niklas Lindström: +1

Stéphane Corlosquet: +0

Gregg Kellogg: +1

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/146

Manu Sporny: this came about during a discussion with reto.

Manu Sporny: "position": ["18.324235", "-36.4387934"],

Manu Sporny: Often people have data which expresses data in tuples.

Manu Sporny: A whole bunch of geo-data matches this pattern. Even if explicit terms are "better", people are not going do use that.

Manu Sporny: other cases are e.g. vectors, circles, or general data pairs

Manu Sporny: "position": {"@id": "geo:position", "@container": [{"@id": "geo:latitude"}, {"@id": "geo:longitude"}]}

Manu Sporny: or this: "coordinates": {"@container": "@list", "@tuple": [{"@id": "geo:latitude"}, {"@id": "geo:longitude"}]}

Niklas Lindström: I am in favor of supporting it - I thought of it when I saw GeoJSON. I came across it when I worked with biographical data at the Royal Library... we're slowly moving towards RDF and I'm using JSON-LD as the target there. There are many complications on that road, may not be able to achieve this... there are certain shapes of data that use this form. I'd like to transform those... [scribe assist by Manu Sporny]

Manu Sporny: ...expressions because they're cumbersome.

Niklas Lindström: However, for GeoJSON, that is a very good use case. [scribe assist by Manu Sporny]

Niklas Lindström: Statistics and measurements as well. [scribe assist by Manu Sporny]

Gregg Kellogg: I see the value of it

Gregg Kellogg: again, compaction complexity might be a problem. But I support it for expressing data

Markus Lanthaler: I agree with the arguments and see the value in it.

Markus Lanthaler: but I'm concerned about all the various ways of expressing data, and the impact of that on understanding data

Manu Sporny: yes, I agree with marcus

Manu Sporny: the issue is what happens when you have JSON data and need to transfer it to JSON-LD

Manu Sporny: it would be nice to figure out a way to add experimental features but not including it in 1.0 proper

Gregg Kellogg: I think the complexity really lies in compaction. You can use a context to understand a specific form. But the general compaction algorithm would suffer if it had to support all kinds of "gleaning"

Gregg Kellogg: we may want to move away from symmetric application of context

Manu Sporny: but that could confuse users

Gregg Kellogg: but will people use framing, or proprietary algorithms?

Manu Sporny: we often use that approach too

Manu Sporny: will compaction mostly be the "pretty print" for JSON-LD?

Gregg Kellogg: graphify addresses the shape issue. It ensures that you can navigate with dot notation consistently.

Gregg Kellogg: framing does the query thing, matches and extracts data

Niklas Lindström: I don't know if we've discussed enough for a vote? [scribe assist by Manu Sporny]

Gregg Kellogg: compaction is useful though; for e.g. graphify

Manu Sporny: even if we break the symmetry between expansion and compaction, I'm concerned about the complexity

Gregg Kellogg: an anecdote: Dave Beckett said about Turtle that a feature was only added when there was lots of complaints about it missing

Gregg Kellogg: we may want to look at macros instead...

Niklas Lindström: Yeah, I'm on the edge for this feature - I like many of the suggestions, but I'm also concerned about the complexity - we may want a pre-processing language? It would be nice to have something declarative in JSON. [scribe assist by Manu Sporny]

Niklas Lindström: We could use IRI templates, etc... so, we might want to have a "third" thing, not a part of the 1.0 JSON-LD spec - that's some sort of GRDDL for JSON-LD w/ a definined macro language for the next version of expansion. [scribe assist by Manu Sporny]

Manu Sporny: we may add a preprocessing step to the JSON-LD API.

Manu Sporny: Discussion about pre-processing step vs. declarative form for modifying a document.

Manu Sporny: Okay, out of time for today - thanks for the call - we'll have another call next week.