Manu Sporny: any updates to the agenda?

Gregg Kellogg: ISSUE-43 and ISSUE-53 - https://github.com/json-ld/json-ld.org/issues/43

Markus Lanthaler: https://github.com/json-ld/json-ld.org/issues/53

Gregg Kellogg: we need to discuss issue 43 and 53

Manu Sporny: Let's focus on the syntax spec first; api spec needs more work

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

Gregg Kellogg: the consequences of having multiple mappings to a single [property] iri

Manu Sporny: so the way we've defined the context is more complex; before the mapping was simple (iri - definition (term, opt coercion)

Gregg Kellogg: before, when you process the context, you used the expanded IRI, not the lexical value of the "term"

Markus Lanthaler: I don't think it was really that clear before

Niklas Lindström: I'm not sure if I'm following - clarification - the problem here is not that there can be different terms for different coercion values w/ the same IRI. [scribe assist by Manu Sporny]

Gregg Kellogg: The problem comes when you apply that to expansion and compaction algorithms. [scribe assist by Manu Sporny]

Gregg Kellogg: if you specify two mappings that both map to the same IRI, it's ambiguous which one you pick. [scribe assist by Manu Sporny]

Niklas Lindström: I'm willing to defend this complexity - it is complex when you have very diverse data. [scribe assist by Manu Sporny]

Niklas Lindström: When you have different objects for the same property - when you want to express JSON - you want to shield people from the details of the object values, which is why we have coercion. [scribe assist by Manu Sporny]

Niklas Lindström: When these two goals collide, there will be a complex situation, regardless. [scribe assist by Manu Sporny]

Niklas Lindström: I think this is defendable - the value gained by the ability to have different terms for the combination of a different property/datatype is greater than not being able to handle potentially varied object data. [scribe assist by Manu Sporny]

Niklas Lindström: If you have that situation, your data is very complex. [scribe assist by Manu Sporny]

Niklas Lindström: I don't think this in and of itself creates any ambiguity - you won't find any specific term for the value type... you have to use the full IRI or generate a CURIE for the prefix defined. [scribe assist by Manu Sporny]

Manu Sporny: I see what gregg is getting at

Markus Lanthaler: https://github.com/json-ld/json-ld.org/issues/43

Gregg Kellogg: {

Gregg Kellogg: "@context":

Gregg Kellogg: {

Gregg Kellogg: "a": {"@id": "http://example.com/foo", "@type": "xsd:integer"},

Gregg Kellogg: "b": {"@id": "http://example.com/foo"}

Gregg Kellogg: },

Gregg Kellogg: "a": "1",

Gregg Kellogg: "b": "1"

Gregg Kellogg: }

Manu Sporny: the ambiguity is which term to pick

Manu Sporny: always pick the lexically smaller value

Manu Sporny: the alternative, to strip this functionality out, or saying that it's undefined is hard; we have use cases for this, and undefined is bad

Manu Sporny: we should turn how conflicts are resolved into a separate issue

Manu Sporny: it does impact the syntax, so we need to discuss it soon

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

Gregg Kellogg: with some more syntax spec changes we can close issue 43

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

Markus Lanthaler: I think this is closely related to https://github.com/json-ld/json-ld.org/issues/68

Niklas Lindström: I believe this issue conflates different things - it talks about disjoint graphs, drop the subtree during processing, and how we handle @ids with lists of IRIs. [scribe assist by Manu Sporny]

Manu Sporny: These are three separate issues, yes. [scribe assist by Manu Sporny]

Manu Sporny: in the beginning of JSON-LD, lists of iris in @id was a syntax "macro" to say same things to different subjects

Markus Lanthaler: I don't see how lists of IRIs in @id and disjoint graphs are related. [scribe assist by Manu Sporny]

Manu Sporny: there are three different issues. we make issue 56 to only be about unknown terms. to allow for "raw" json in json-ld

Gregg Kellogg: IMO, ignore sub-tree

Niklas Lindström: This is where the conflation may have begun. When I discussed this, I did it from my use cases' perspective - I have @rev to represent reverse relations... it's a magic key, the value is a JSON object which has what looks like normal terms pointing to resources. [scribe assist by Manu Sporny]

Niklas Lindström: They demonstrate the inverse - if we drop the entire subtree, then I can put this data in and the data in the subtree looks like JSON-LD, but nobody has to care about that. It's tempting to me to say that I want to keep the subtree, but I realize that if want @rev, then we have this problem where we have keys that mean nothing... we have a two step path down, and that's too complex... [scribe assist by Manu Sporny]

Manu Sporny: ...to handle.

Manu Sporny: I agree

Gregg Kellogg: the spec's been updated to fix that

Niklas Lindström: Ivan suggested that instead of allowing "@id" : [{}, {}, {}] - we should use "@data": [{}, {}, {}] to represent a disjoint graph. [scribe assist by Manu Sporny]

Niklas Lindström: if we allow processors to deep-dive into unknown terms, we don't have to define @data... deep dive processors would just find the data... as we just discussed, this is too complicated. [scribe assist by Manu Sporny]

Markus Lanthaler: Can you explain why this is complicated? [scribe assist by Manu Sporny]

Gregg Kellogg: we need to be able to ignore contexts

Niklas Lindström: If I do something like rev.partOf, it creates an issue - I don't want that to be processed. [scribe assist by Manu Sporny]

Manu Sporny: if we allow deep dives; when you compact the data; the result will look very different

Markus Lanthaler: it makes sense.

Manu Sporny: it is dropped entirely

Gregg Kellogg: agreed

Markus Lanthaler: ok

Gregg Kellogg: it needs to be clear to say when a key is definitively unmapped

Manu Sporny: +1

Niklas Lindström: +1

Gregg Kellogg: +1

Markus Lanthaler: +1

David I. Lehn: +0

Niklas Lindström: +1 (i.e. JSON null)

Manu Sporny: +1

Gregg Kellogg: +1

Markus Lanthaler: "name": { "@type": null }

Markus Lanthaler: +1

David I. Lehn: +0

Markus Lanthaler: +1

Niklas Lindström: +1

Manu Sporny: +1

David I. Lehn: +0

Gregg Kellogg: +1

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

Gregg Kellogg: we have no real use cases for it, do we?

Markus Lanthaler: can you give a list an iri?

Gregg Kellogg: you can have a list as the value of an @id

Markus Lanthaler: { "@id": "xxxx", "@type": "@list", "@value": [ list values ] }

Niklas Lindström: You can use RDF terms to create an RDF list with an ID and then for that value, rdf:rest the rest... it would look terrible, but you could do it. [scribe assist by Manu Sporny]

Niklas Lindström: This is not specified currently... [scribe assist by Manu Sporny]

Niklas Lindström: What about {@list: []} in a list?

Niklas Lindström: Like this: {@list: [ {@list: [1, 2]}, {@lisr: [3, 4] ]} is "a list of lists". But the issue is should [[1,2], [3,4]] *mean* that

Niklas Lindström: If we supported this syntax, we could support lists of lists. [scribe assist by Manu Sporny]

Markus Lanthaler: I have a use case (another issue) where a list has an IRI and can be referenced

Niklas Lindström: http://example.com/list-with-id a rdf:List, rdf:first 1, rdf:rest (2) .

Gregg Kellogg: there is a way to do it in RDF, round-trips are of concern

Manu Sporny: yes, the round-trip is of great concern

Niklas Lindström: I agree, we are discussing something very complex. [scribe assist by Manu Sporny]

Niklas Lindström: If you need to do it, you can do it - any sort of syntactic short-hand is an issue. [scribe assist by Manu Sporny]

Niklas Lindström: Serializers for RDF which have a short-hand for lists stop using the short-hand if the list is described with other properties or the list is not a list of bnodes. The short-hand breaks down. [scribe assist by Manu Sporny]

Niklas Lindström: We can use the gruesome and verbose list mechanism without any changes - we shouldn't try to create separate support for this. [scribe assist by Manu Sporny]

Niklas Lindström: What about - [ [ … ] ]

Niklas Lindström: That is not supported, to clarify. [scribe assist by Manu Sporny]

Manu Sporny: Niklas did mention this: {@list: [ {@list: [1, 2]}, {@list: [3, 4] ]}

David I. Lehn: Good call.