JSON-LD Community Group Telecon

Minutes for 2012-04-24

Agenda
http://lists.w3.org/Archives/Public/public-linked-json/2012Apr/0050.html
Topics
  1. WWW2012 Conference
  2. ISSUE-106: JSON-LD 1.0 @graph syntax
  3. ISSUE-102: Can JSON-LD keywords be re-defined in the @context?
  4. ISSUE-103: Re-introduce @datatype as @valuetype
  5. ISSUE-92: Limit JSON-LD properties to one @list per property
  6. ISSUE-91: Re-definition of keywords
Resolutions
  1. Adopt the 6 points in ISSUE-106 along with Gregg and Longley's proposal for @graph processing in framing as the way we approach named graph support in JSON-LD.
  2. JSON-LD keywords MUST NOT be re-defined in the @context. If a JSON-LD processor detects that a JSON-LD keyword is being re-defined, it MUST throw an exception.
  3. Do not re-introduce typing JSON-LD @value via something like @datatype or @valuetype.
  4. If the result of IRI compaction has an @container @list and there are multiple @list values, throw an exception. When doing IRI compaction do not select terms (other than absolute IRIs) that have @container @list if the value has more than one list.
  5. JSON-LD allows sets of lists except where it conflicts with the previous resolution.
  6. Remove step #1: "If iri is rdf:type, return @type." from the Compact IRI algorithm.
  7. Add an option to the fromRDF algorithm to skip step 5.6 "If the property is rdf:type use @type" to support the use of a term in place of the @type keyword during conversion from RDF to JSON-LD.
Action Items
  1. gkellogg to create issue on describing fragid semantics in JSON-LD
Chair
Manu Sporny
Scribe
Gregg Kellogg
Present
Gregg Kellogg, Manu Sporny, Markus Lanthaler, Niklas Lindström
Audio Log
audio.ogg
Gregg Kellogg is scribing.
Gregg Kellogg: There is one addition to the agenda, possibly - use of fragment identifiers in JSON-LD - IANA considerations - how fragment identifiers are interpreted. [scribe assist by Manu Sporny]
Manu Sporny: Do we need to specify something since it's an IRI? [scribe assist by Manu Sporny]
Gregg Kellogg: Important for follow-your-spec-nose back to MIMEType definition. [scribe assist by Manu Sporny]
ACTION: gkellogg to create issue on describing fragid semantics in JSON-LD

Topic: WWW2012 Conference

Markus Lanthaler: talk at WWW2012 on JSON-LD
… TimBL made some disparaging remarks on JSON-LD in a separate discussion.
… the result was to increase attendance at the talk and lead to some realization that JSON-LD is much different than RDF/XML; a more natural fit.
… many big companies interested, but waiting for the spec to become stable.
… there is an issue in adapting existing syntax due to problems in mapping their ids to IRIs.
… some form of IRI template, or JSON-LD macros could help supplement this.
Manu Sporny: had some discussions. TimBL is off in his criticism.
… RDF/XML is primarily a serialization of RDF in XML. hard to read and hard to use.
… JSON-LD is different; it can be converted to RDF, but it is not principally an RDF serialization.
… It's a linked data format designed for people that already use JSON.
… Important to understand that it is a different kind of linked data format. This seems to have been appreciated by many other people.
… I don't think we should ignore this, but make a concerted blog post to answer the criticism.
... There is some need for IRI templates...
Markus Lanthaler: mostly talking to REST people having existing JSON APIs. They'd like to upgrade to JSON-LD.
… works if ID is already a relative IRI, but existing identifiers are typically not IRIs.
… a template mechanism would allow them to be coerced to IRIs.
… however, this was not widely understood, and the spec should address.
Manu Sporny: can we outline a use case?
Markus Lanthaler: most already had an API in place having the data, but not simple to just add a @context, because the IDs can't just be made into IRIs.
Gregg Kellogg: Did you have any interaction with the Wikidata folks? [scribe assist by Manu Sporny]
Markus Lanthaler: Nope, wasn't able to find them at the conference. [scribe assist by Manu Sporny]
Gregg Kellogg: I've done a bit of reaching out to them - updated their JSON-LD page... need to find out where they're going. They may be doing their own proprietary thing. [scribe assist by Manu Sporny]
Gregg Kellogg: http://meta.wikimedia.org/wiki/Talk:Wikidata/Data_model
Gregg Kellogg: There is some concern in there about expressing statements about multiple @graphs [scribe assist by Manu Sporny]
Gregg Kellogg: Reification of statements is an issue - DBPedia makes a separate graph per statement so that they can describe the provenance separately. This is the problem we get into with named graphs - some want to use named graphs for reification of statements, others want to use it to describe a different set of files that are imported (which is how they're used in SPARQL) [scribe assist by Manu Sporny]
Gregg Kellogg: The things are pretty equivalent in a model-theoretic sense. At the snik level, (describes a statement and all assertions about that statement), when you get to a larger wiki - where you have much more stuff involved than just that level of granularity - it isn't as useful. If there is a way to turn the graphs upside-down, instead of having statements that ... graph that references... [scribe assist by Manu Sporny]
Manu Sporny: ...assertions upon it.
Markus Lanthaler: Could we solve that by allow a string value for @graph? [scribe assist by Manu Sporny]
Gregg Kellogg: Could we have something like "@ingraph"? [scribe assist by Manu Sporny]
Gregg Kellogg: These aren't really syntax issues - go through the data model talk page and see if you can make the case for it? This is a natural fit for JSON-LD. [scribe assist by Manu Sporny]

Topic: ISSUE-106: JSON-LD 1.0 @graph syntax

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/106
Manu Sporny: discussion on @graph issues.
Manu Sporny: Support named graphs by having @id and @graph at the same level, where @id expresses the name of the graph.
Manu Sporny: Both IRIs and BNode-like labels (starting with '_:') can be used in @id to name a graph.
Manu Sporny: The @graph keyword is alias-able.
Manu Sporny: The @graph keyword is always associated with an IRI - in JSON, represented by a string, an object with an @id, or an array of objects with @ids.
Manu Sporny: A JSON-LD property MAY be associated with a {"@graph": ...} object.
Manu Sporny: The JSON-LD keywords MUST NOT be associated with a {"@graph": ...} object - especially @id and @value.
Gregg Kellogg: The documents that we have currently are consistent with these rules. [scribe assist by Manu Sporny]
Gregg Kellogg: We need to discuss how to deal with @graph and framing - that's where it has the biggest impact. [scribe assist by Manu Sporny]
Gregg Kellogg: RDF transformation to-and-from have been updated w/ @graph. [scribe assist by Manu Sporny]
Markus Lanthaler: "foaf:org": { "@graph": ... } ??
Gregg Kellogg: I think the documents are pretty consistent with this interpretation... biggest outstanding issues is impact of @graph on framing. Easiest way to deal with that is that framing merges all of these statements. [scribe assist by Manu Sporny]
Gregg Kellogg: if a frame includes @graph within it, it is not in a flattened graph space, and the components of each graph are flattened separately. [scribe assist by Manu Sporny]
Gregg Kellogg: You flatten, individually in each graph, then you can have semantics where you reference graphs - you traverse into each of the named graphs. Requires how you speak of a graph - some @id matching in a frame, find specific graphs based on their identifiers - not something we wanted to get into right now... perhaps in JSON 1.0, we only support flattened graphs for framing. [scribe assist by Manu Sporny]
Manu Sporny: @graph points to an identifier. It's a string, interpreted as an IRI, or an object, or an array of ids/objects.
Markus Lanthaler: { "@id": "id-graph", "@graph": { "@id": "obj-id", ... } }
Markus Lanthaler: What happens when you have "@graph": "http://example.com/#g1" ? [scribe assist by Manu Sporny]
Gregg Kellogg: It means it's a reference to another graph - you can dereference that URL and get another graph. [scribe assist by Manu Sporny]
Gregg Kellogg: Being able to reference a set of RDF statements is necessary but not sufficient - you would need to add something to the graph itself to state that those statements refer to something else. [scribe assist by Manu Sporny]
Gregg Kellogg: This is what Manu was concerned about - getting into the "semantics" discussion... we need to stick with the syntax discussion. [scribe assist by Manu Sporny]
Markus Lanthaler: Yes, but isn't this about syntax? [scribe assist by Manu Sporny]
Manu Sporny: Not really, both syntax and semantics. [scribe assist by Manu Sporny]
Gregg Kellogg: We can just say that you point to an IRI and we don't have to go into the meaning of that IRI, let the RDF WG deal with that. When you dereference that IRI, you insert the graph into the document - but JSON-LD processors don't need to do that. [scribe assist by Manu Sporny]
Markus Lanthaler: You wouldn't need to go out to the Web and retrieve it? [scribe assist by Manu Sporny]
Gregg Kellogg: no, it's the same thing with other IRIs - we don't have to go out and fetch those either. [scribe assist by Manu Sporny]
Gregg Kellogg: If I were to expand a document with @graph referencing a string - I would replace that with an object containing a subject reference. [scribe assist by Manu Sporny]
Markus Lanthaler: "@graph": "http://example.com/#g1" == "@graph": { "@id": "http://example.com/#g1" }
{"@id": foo, "@graph": bar} => {@id: http://foo, "@graph: {"@id": "http://bar"}}
"@id": foo, "@graph": bar} => {@id: http://foo, "@graph:[ {"@id": "http://bar"}]}
Gregg Kellogg: What would it mean if you had an object with {"@id": ... , "@graph": ...} - how is that handled in framing... [scribe assist by Manu Sporny]
Gregg Kellogg: If I have a named graph that includes an object that has a named graph, when it is flattened, the identifier for that graph is placed at the top, but all properties are placed into the graph. [scribe assist by Manu Sporny]
{@id: foo: @graph: {prop: foo, @id: bar, @graph:{ "prop": baz}}}
[@id: foo: @graph: {@id: bar; prop: foo}}, {@id: bar, @graph {"prop": baz}}
Gregg Kellogg: What that is saying is this: you have a named graph identified by 'foo', which references and object identified by 'bar' [scribe assist by Manu Sporny]
Gregg Kellogg: @id bar exists in named graph 'foo', and in the default graph. [scribe assist by Manu Sporny]
Gregg Kellogg: if you look at the impact on the RDF APIs, it's useful when you take one of these graphs, turn it into RDF and then back into JSON-LD. [scribe assist by Manu Sporny]
Gregg Kellogg: When you turn it into RDF, all @graph @ids become the fourth element in a quad. [scribe assist by Manu Sporny]
Gregg Kellogg: When you go back to JSON-LD from RDF - then you get the @id and the @graph back, but it removes the nesting. [scribe assist by Manu Sporny]
Gregg Kellogg: That's the interpretation we could have with framing - the first step in framing is a flattening operation - you could almost flatten by turning the document into RDF, and then back into JSON-LD... The only issue is that you lose order. The JSON-LD algorithm maintains order in the original document. The graphs are isomorphic otherwise. [scribe assist by Manu Sporny]
Manu Sporny: general consensus on this approach
PROPOSAL: Adopt the 6 points in ISSUE-106 along with Gregg and Longley's proposal for @graph processing in framing as the way we approach named graph support in JSON-LD.
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
RESOLUTION: Adopt the 6 points in ISSUE-106 along with Gregg and Longley's proposal for @graph processing in framing as the way we approach named graph support in JSON-LD.
Markus Lanthaler: Do we want to have a .flatten() API call? [scribe assist by Manu Sporny]
Manu Sporny: We had a call like that in the original JSON-LD API, but removed it because we weren't using it. [scribe assist by Manu Sporny]

Topic: ISSUE-102: Can JSON-LD keywords be re-defined in the @context?

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/102
Manu Sporny: two options, allow it but warn, next to throw an exeption, 3rd to ignore (except for @type)
… like markus' idea to ignore statements, but if they're invalid, we should throw an exception.
Markus Lanthaler: could be a log message instead of an exception.
Manu Sporny: this is different than document processing, it's an invalid context definition.
… if we ignore the statements, people could have markup in the document that is ignored, but changes meaning if/as/when it is defined.
… this helps avoid a backwards compatibility issue, and that overriding is not allowed.
Markus Lanthaler: could prevent some innovations with proprietary extensions.
Manu Sporny: we do address niklasl's use case by allowing @type to be overridden.
… are there other potential innovations?
… we can provide guidance on where innovation is allowed.
Manu Sporny: Does this address Niklas' issue? [scribe assist by Manu Sporny]
Markus Lanthaler: Yes, except for the fromRDF translation... [scribe assist by Manu Sporny]
Markus Lanthaler: We may not need to do anything about that, though. [scribe assist by Manu Sporny]
Markus Lanthaler: I think he was concerned if re-definition of @type was supported... fromRDF is a concern... but we don't know if it's really an issue. [scribe assist by Manu Sporny]
PROPOSAL: JSON-LD keywords MUST NOT be re-defined in the @context. If a JSON-LD processor detects that a JSON-LD keyword is being re-defined, it MUST throw an exception.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
RESOLUTION: JSON-LD keywords MUST NOT be re-defined in the @context. If a JSON-LD processor detects that a JSON-LD keyword is being re-defined, it MUST throw an exception.

Topic: ISSUE-103: Re-introduce @datatype as @valuetype

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/103
Manu Sporny: two things came out of @type discussion:
1) want @type defined to be something else.
2) people don't understand that @type has different meanings depends on where it's used.
… question here is if we re-introduce @datatype as @valuetype.
Markus Lanthaler: confusion from RDF people?
Manu Sporny: issue from RDF knowledgeable people.
… also, dlongley had a similar problem.
Gregg Kellogg: My thought is that it's not compelling enough to make a big change to the language right now. People are looking to us to stabilize the syntax. It's not an unreasonable syntax. It's implemented in different languages, let's not touch this right now. Keep @type as it is right now. [scribe assist by Manu Sporny]
Markus Lanthaler: also think we should stay the same.
Niklas Lindström: my concern is that @type does two things, one is that it is an alias for rdf:type.
Niklas Lindström: A bit of a concern for me - @type does two things, it's just an alias for rdf:type in one way... if we specify it clearly enough, it's not an issue. [scribe assist by Manu Sporny]
… if we specify enough, that may not be an issue.
Manu Sporny: we also decided that JSON-LD keywords, including @type, can't be re-defined.
… however, we don't think that impacts niklas' usage.
Niklas Lindström: wanted to be sure that defined type would be used.
Niklas Lindström: one of the values of compaction is to know the form of the generated JSON-LD.
… if I want to say that it must be in a list, and I can't re-defined @list, it would be a problem.
Manu Sporny: back to issue #103
PROPOSAL: Do not re-introduce typing JSON-LD @value via something like @datatype or @valuetype.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: -0.5
RESOLUTION: Do not re-introduce typing JSON-LD @value via something like @datatype or @valuetype.

Topic: ISSUE-92: Limit JSON-LD properties to one @list per property

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/92
Manu Sporny: in context you define to terms that have the same @id. Both have a @list, when you expand, they're merged.
… the problem comes in expansion, where the order becomes an issue.
Markus Lanthaler: problem isn't in expansion, as order of two lists doesn't matter.
… in compaction, if there is @list containership, it would create a list of lists.
Manu Sporny: throw an error when compacting and using a property with @list container with multiple values.
Manu Sporny: suggested: During compaction a JSON-LD processor MUST throw an exception when it detects two or more @lists associated with a property that is itself a @container: @list that will become compacted into a single property.
Markus Lanthaler: During compaction a JSON-LD processor MUST throw an exception when it detects two or more @lists associated with a property IRI that is itself a @container: @list
Manu Sporny: Discussion about how the algorithms currently work and an optimization/clarification.
Gregg Kellogg: We may not need to say anything as the spec text may already accomplish this. [scribe assist by Manu Sporny]
[{@list}, {@list}]
[[][]]
Gregg Kellogg: If I have that - and did simple compaction, it woudl turn into that ^^^ [scribe assist by Manu Sporny]
Gregg Kellogg: This has to do with compaction step 2.2 [scribe assist by Manu Sporny]
Markus Lanthaler: This is a corner case of the current spec that we can't support in compaction. I don't think we need to disallow having multiple lists per property just because of this. [scribe assist by Manu Sporny]
Manu Sporny: The spec should say something about this, because it's not straight-forward. [scribe assist by Manu Sporny]
Gregg Kellogg: Yes, compaction algorithm should say something about this. [scribe assist by Manu Sporny]
PROPOSAL: When compacting values with terms that have @container @list, and there are multiple @list values, through an exception.
Gregg Kellogg: +1
Manu Sporny: +1
also, IRI compaction should not select terms (other than absolute IRIs) that have @container @list if the value has more than one list.
Markus Lanthaler: +1
Manu Sporny: We should combine those statments into one proposal.
PROPOSAL: If the result of IRI compaction has an @container @list and there are multiple @list values, throw an exception. When doing IRI compaction do not select terms (other than absolute IRIs) that have @container @list if the value has more than one list.
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Niklas Lindström: +1
RESOLUTION: If the result of IRI compaction has an @container @list and there are multiple @list values, throw an exception. When doing IRI compaction do not select terms (other than absolute IRIs) that have @container @list if the value has more than one list.
PROPOSAL: JSON-LD allows sets of lists except where it conflicts with the previous resolution.
Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Niklas Lindström: +1
RESOLUTION: JSON-LD allows sets of lists except where it conflicts with the previous resolution.

Topic: ISSUE-91: Re-definition of keywords

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/91
Manu Sporny: We had postponed decision on ISSUE-91 because we needed to address the following: 1) if we want to reintroduce @datatype, 2) if keywords can be redefined, 3) if there is an initial context that specifies '@type' as syntactic sugar (@type is just like any other property)
Manu Sporny: We resolved #1 and #2
Niklas Lindström: If we resolved #1 and #2, we have said that keywords can't be re-defined and so can't be defined in an initial context. [scribe assist by Manu Sporny]
Niklas Lindström: https://github.com/json-ld/json-ld.org/issues/102
Gregg Kellogg: I believe what we said is that you can't use "@id" for @type... can you create a context definition that uses "@container": "@set"? [scribe assist by Manu Sporny]
Niklas Lindström: This could be a term selection issue - if we change that, we could address my use case. [scribe assist by Manu Sporny]
Markus Lanthaler: During expansion, we don't expand @type to the full IRI anyway. [scribe assist by Manu Sporny]
Gregg Kellogg: I think it's sufficient to override the selection in fromRDF() and remove it from IRI compaction. If you have a property like "rdf:type", it wouldn't be affected. [scribe assist by Manu Sporny]
http://json-ld.org/spec/latest/json-ld-api/#convert-from-rdf-algorithm
PROPOSAL: move step 1 in IRI Compaction Algorithm to the end of the algorithm, so that @type is used if no other definition is found, instead of the absolute IRI forrdf
Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Markus Lanthaler: "rdf:type": { "@id": "test", "label": "labelvalue" } -> expand -> compact -> "@type": { "@id": "test", "label": "labelvalue" }
PROPOSAL: Remove step #1; "If iri is rdf;type, return @type." from the Compact IRI algorithm.
Niklas Lindström: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Manu Sporny: +1
RESOLUTION: Remove step #1: "If iri is rdf:type, return @type." from the Compact IRI algorithm.
PROPOSAL: Add an option to the fromRDF algorithm to skip step 5.6 "If the property is rdf;type use @type" to support the use of a term in place of the @type keyword during conversion from RDF to JSON-LD.
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: +1
RESOLUTION: Add an option to the fromRDF algorithm to skip step 5.6 "If the property is rdf:type use @type" to support the use of a term in place of the @type keyword during conversion from RDF to JSON-LD.