Manu Sporny: What do we do when @id has multiple strings in an array?
Manu Sporny: We have four options...
Only use the first value in the @id array.
Only use the last value in the @id array.
Effectively do #1 or #2 by modifying the @id value to only contain the first/last value.
Throw an exception/error.
Manu Sporny: Any other options?
Gregg Kellogg: We could also say that it's implicitly a list - but if we add @set, that decision would be arbitrary...
Markus Lanthaler: Then what would the output be?
Gregg Kellogg: The value would be the value of the first item in the list - the first bnode. You can have a list be in the subject position.
Gregg Kellogg: That is tying our hands, though.
Gregg Kellogg: I say, probably not do that. If we want to adopt this syntax for something else, then we should probably throw an exception so we don't get b/c issues. I think it's pretty unlikely that we want to go this way. We probably will use another keyword to make it more explicit.
Manu Sporny: I think the best option is throw an exception, buys us time... least dangerous option.
Gregg Kellogg: If the value of @id is null... it should be as if there was no value there at all.
PROPOSAL: If a string is found in an array that is the value of the "@id" key, a JSON-LD Processor MUST throw an exception.
David I. Lehn: does it complicate processors to detect this vs just leaving the behavior undefined?
Niklas Lindström: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
David I. Lehn: +1
Niklas Lindström: .. also expecting that we're moving away from arrays in @id for multiple subjects as well (when we come to that issue)
Manu Sporny: We should be very specific in what processors should do, otherwise, there might be interoperability issues.
RESOLUTION: If a string is found in an array that is the value of the "@id" key, a JSON-LD Processor MUST throw an exception.
Manu Sporny: This has to do with how we represent graphs in JSON-LD.
Niklas Lindström: I think we've confused two issues... 63 and 68. We may be confusing "multiple graphs" with "multiple subjects in one graph". I think we can close this issue with a reference to issue 68
Niklas Lindström: For this issue to work, we would have to have literal graphs... how do you use a literal graph as a subject?
Niklas Lindström: If you have graphs, you have IDs for graphs and then you could use them for subjects.
Gregg Kellogg: I think the syntax for multiple graphs is probably pretty well set... I don't think the RDF WG making any big changes to TRiG... quads aren't going to change... so RDF WG is working on /semantics/ behind multiple graphs.
Gregg Kellogg: It would be one more syntax in a growing set...
Markus Lanthaler: agree to put on hold for now
Gregg Kellogg: This is about provenance - an application of multiple graphs - we can hold off discussion on the provenance issue. We should hold until there is some consensus around expressing provenance on multiple graph syntaxes.
Gregg Kellogg: We could provide support for multiple graphs, but may want to discuss a syntax for multiple graphs. Provenance goes further than a particular serialization.
Niklas Lindström: I agree w/ what Gregg said, I also comment on that in the issue - what the issue speaks of can be done w/o named graphs at all.
Niklas Lindström: If you use triples talking about provenance, you don't need named graphs... you can do that today. Provenance can be done w/o named graphs. When you start to describe a graph, you create another graph describing that graph.
Niklas Lindström: .. provenance information can be given for information resources (e.g. an rdf document); *if* you want to describe graphs themselves, that requires graph literals, which is in #68
PROPOSAL: Put the discussion of Provenance on hold until the RDF WG produces a proposal for provenance.
Gregg Kellogg: +1
Manu Sporny: +1
David I. Lehn: +1
Niklas Lindström: +1
Markus Lanthaler: +1
RESOLUTION: Put the discussion of Provenance on hold until the RDF WG produces a proposal for provenance.
Topic: ISSUE-64: Make clear how type and language coercions work
Gregg Kellogg: We should keep things a bit open on how we specify this...
Gregg Kellogg: Unless otherwise specified, the use of null as a value MUST be treated as if the value was never specified; i.e., it has no effect.
Gregg Kellogg: Unless otherwise specified, the use of null as a key is treated as if the key/value was never specified, and values of that key are not processed.
Manu Sporny: Is null allowed as a key?
Niklas Lindström: Not in JSON...
Manu Sporny: Yes, confirmed, it changes it to "null" when you serialize, we don't need the second statement.
Markus Lanthaler: What if you do "@context": null ?
Gregg Kellogg: "@context": null should clear the current context, useful when used in an array
Niklas Lindström: What does that mean? If you clear the context?
Gregg Kellogg: When "@context": null is specified, it clears the active context.
Gregg Kellogg: You could set @id to null, you could set @language to null, you could set term to null, you could set @type to null...
Niklas Lindström: That example - if that key doesn't mean anything, you should still look at the thing in the @container. We don't have time to think of this right now, but putting it out there as something that could give meaning to "@id": null
Niklas Lindström: Let's put this discussion on the mailing list.
Manu Sporny: You're saying, let's be specific about 'null'
PROPOSAL: If "@language"; null is specified in a local context, language coercion is removed from the active context.
Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
David I. Lehn: +1
Markus Lanthaler: +1
RESOLUTION: If "@language": null is specified in a local context, language coercion is removed from the active context.
Topic: ISSUE-65: Handling of data that doesn't contain triples.
David I. Lehn: about the second proposal, a top level [] is still valid and needs to be supported since it's representing no data
Manu Sporny: This has to do with existential information - do we want to support statements like: {} and [] ?
Niklas Lindström: {"key": {}} vs. {"key": null}
Manu Sporny: There are two proposals - If an author wants to express existential information and have it survive the compaction and expansion processes, then they MUST assign an identifier to it... and All empty JSON arrays and JSON objects MUST be optimized out of the output during compaction or expansion.
Niklas Lindström: There is a difference here - JSON supports {} and []
Niklas Lindström: If we support empty object, that's natural...
Gregg Kellogg: To say it's not supported, would generate a special case... that's inconsistent.
Niklas Lindström: In the general case, an empty list doesn't mean anything from the JSON-LD perspective... if it is a @list, it should be the empty list.
Markus Lanthaler: I think in both cases, we should remove it.
Markus Lanthaler: If it's coerced to a list or not, we should remove it.
Niklas Lindström: If it is coerced to a list, the value is an empty list... we can't just remove it.
Markus Lanthaler: An empty set is also an empty set... why do we remove that?
Niklas Lindström: owl:Nothing
Niklas Lindström: Something coerced to a list as an empty list has meaning... we would be destroying data if we didn't add that.
Manu Sporny: So the counter-proposals are this: If we have {}, we generate a bnode identifier for it... if we have [] (and it isn't coerced as a list), then it's left as-is... if we have [] (and it is coerced to a list), then it isrdf:nil.
Gregg Kellogg: Part of the compaction algorithm is to normalize, normalization goes to RDF, the result of normalizing doesn't generate a triple... so data is removed during normalization to create the empty set.
Gregg Kellogg: When you generate RDF, no triples are generated for [], thus round-trip would fail.
Gregg Kellogg: If we become inconsistent with RDF, we're in dangerous territory.
Gregg Kellogg: I think empty lists w/o coercion means - remove it from the data, that's what RDF does. I think empty lists w/ coercion to list meansrdf:nil - that's what RDF does... we should do that.
Niklas Lindström: Agreed.
Markus Lanthaler: But if we destroy empty sets, we're not being consistent.
Niklas Lindström: I think we have to be practical about this...
Gregg Kellogg: This may be generated automatically, compaction should eliminate the redundancies.
Niklas Lindström: If I use "@container": "@set" - I have lots of terms that have to be multiple if they are present. Lots of terms for different types of objects.
Gregg Kellogg is scribing.
PROPOSAL: If '[]' is specified as a value for a key in a JSON-LD document, and no "@container"
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: we're pushing "@container": "@set" off for now.
Markus Lanthaler: [] is implicitly a @set
Niklas Lindström: conceptual trickiness is that @set does not imply a value, but a representation.
… difference is between "raw" JSON and JSON-LD
… if we had interpreted arrays as list by default, it would have the @list meaning. Since we don't, removing it is consistent.
Niklas Lindström: multiple values in RDF can be interpreted in different ways (more "soft")
Manu Sporny: if we put in support for @container: @set, what does [] mean in RDF?
Niklas Lindström: it does not have an RDF representation; as if it wasn't there.
Manu Sporny: +1
… if we don't explain, some people would be confused about @set with [].
Markus Lanthaler: concerned that we would lose the assertion that there is an empty set.
Manu Sporny: postpone for now, but personally leaning toward's niklas' interpretation.
… See that JSON developers might be confused, but the fact that you're now in compacted JSON-LD land creates a consistent nuanced interpretation.
Niklas Lindström: was going to mention that there is a small semantic interpretation.
… syntactically, JSON imposes an order, but there is no way to specify the semantics in JSON.
Manu Sporny: an empty object should generate a BNode identifier.
POSTPONED: If '[]' is specified as a value for a key in a JSON-LD document, and no "@container": "@list" is specified for the associated key, then the value MUST be removed from compacted output.
Manu Sporny: We need to have more reflection and discussion on this... [scribe assist by Manu Sporny]
Manu Sporny: But we can discuss the {} issue.... [scribe assist by Manu Sporny]
PROPOSAL: If '{}' is used as a value in a JSON-LD document, then a blank node identifier MUST be generated for the object during normalization.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
David I. Lehn: +1
Markus Lanthaler: +1
RESOLUTION: If '{}' is used as a value in a JSON-LD document, then a blank node identifier MUST be generated for the object during normalization.
Manu Sporny: Let's skip the named graphs stuff for now...
Topic: ISSUE-69: Remove media type parameter option "form=compacted"
Manu Sporny: Markus raised the issue: does form=compacted actually mean anything?
… different contexts create a different compacted form.
… since it doesn't express anything specific, we should remove form=compacted.
… counter argument, is that it is used in payswarm specifications, so that developers can be sure they're getting back something that can be directly operated upon.
… we can say registration service at a given url, login at another, and is very flat.
… If we didn't have form=compacted, there would be no way for the developer to know that they were getting back something that was already compacted.
Markus Lanthaler: compaction works by supplying a context, but payswarm uses 6 different contexts.
Manu Sporny: form=compacted might need to also pass the IRI of the context used for compaction.
Manu Sporny: for payswarm, we can say that if you make a call to a service, you must compact with a specific context, otherwise it must be made explicit.
Markus Lanthaler: saying it's compacted doesn't convey enough information.
Niklas Lindström: … or application/rdf+jsonld;custom=web-key
Niklas Lindström: … or another vendor media-type altogether: application/vnd.payswarm.webkey+jsonld
Markus Lanthaler: we start specifying too much.
Manu Sporny: don't want to tie the syntax spec to the api spec.
Markus Lanthaler: puts too much burden on other implementations.
Niklas Lindström: the common case is that you define a vendor media type, that can define what it means, and documents that it is represented by JSON-LD.
… if you want to negotiate on an explicit form, the use of a different media type enables this.
… the client can be very explicit about what data it wants, and it's up to the service to provide it or not
Manu Sporny: in payswarm, we want people to be able to add other contexts, allowing them to layer other things on top of it, as long as there is no conflict.