- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 24 Jul 2012 13:59:24 -0400
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
Thanks to Niklas for scribing! The minutes from today's call are now available here: http://json-ld.org/minutes/2012-07-24/ Full text of the discussion follows including a link to the audio transcript: -------------------- JSON-LD Community Group Telecon Minutes for 2012-07-24 Agenda: http://lists.w3.org/Archives/Public/public-linked-json/2012Jul/0040.html Topics: 1. ISSUE-120: Expand @type to @id-objects 2. ISSUE-114: JSON-LD Grammar 3. ISSUE-142: Allow terms to expand to multiple IRIs 4. ISSUE-144: @context in coercion rules 5. ISSUE-146: Support array position to property binding Resolutions: 1. When @id is found as a value in an object associated with @type, a handler callback is called to handle the issue. 2. Express the JSON-LD Grammar in prose with supporting tables/examples. Clarify that violating the grammar does not necessarily mean that a JSON-LD processor will not process the document. 3. Support a single term expanding to multiple IRIs when an array of @ids are associated with a single term in the @context. 4. Do not support embedding @contexts within a @context to re-define the IRI that a term maps to. Action Items: 1. Gregg and Manu to improve the JSON-LD Grammar section in the JSON-LD Syntax specification. Chair: Manu Sporny Scribe: Niklas Lindström Present: Manu Sporny, Markus Lanthaler, Niklas Lindström, Gregg Kellogg, Stéphane Corlosquet Audio: http://json-ld.org/minutes/2012-07-24/audio.ogg 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] Niklas Lindström is scribing. Topic: ISSUE-120: Expand @type to @id-objects 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 PROPOSAL: When @id is found as a value in an object associated with @type, a handler callback is called to handle the issue. Markus Lanthaler: +1 Manu Sporny: +1 Gregg Kellogg: +1 Niklas Lindström: +1 RESOLUTION: When @id is found as a value in an object associated with @type, a handler callback is called to handle the issue. 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. Topic: ISSUE-114: JSON-LD Grammar 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 PROPOSAL: Express the JSON-LD Grammar in prose with supporting tables/examples. Clarify that violating the grammar does not necessarily mean that a JSON-LD processor will not process the document. Gregg Kellogg: +1 Manu Sporny: +1 Markus Lanthaler: +1 Niklas Lindström: +1 RESOLUTION: Express the JSON-LD Grammar in prose with supporting tables/examples. Clarify that violating the grammar does not necessarily mean that a JSON-LD processor will not process the document. 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 ACTION: Gregg and Manu to improve the JSON-LD Grammar section in the JSON-LD Syntax specification. Topic: ISSUE-142: Allow terms to expand to multiple IRIs 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"]}} PROPOSAL: Support a single term expanding to multiple IRIs when an array of @ids are associated with a single term in the @context. 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) RESOLUTION: Support a single term expanding to multiple IRIs when an array of @ids are associated with a single term in the @context. 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] Topic: ISSUE-144: @context in coercion rules 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] PROPOSAL: Do not support embedding @contexts within a @context to re-define the IRI that a term maps to. Markus Lanthaler: +1 Manu Sporny: +1 Niklas Lindström: +1 Stéphane Corlosquet: +0 Gregg Kellogg: +1 RESOLUTION: Do not support embedding @contexts within a @context to re-define the IRI that a term maps to. Topic: ISSUE-146: Support array position to property binding 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? .. discussion about framing vs. graphify 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. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: Which is better - RDFa Lite or Microdata? http://manu.sporny.org/2012/mythical-differences/
Received on Tuesday, 24 July 2012 18:00:33 UTC