Option to specify level of compaction for literals & resources

[azaroth42]

Merging the almost-duplicate #3 and #6, which were accepted individually as use cases.

In order to ensure a particular JSON surface structure, where entries in an array are always presented as a JSON object regardless of whether it would be unambiguous to further compact the result, it is necessary to add a new feature to declare this type of compaction is desired.

For example, a resource where only the URI is known will compact to a single string when the context declares the property as @type: @id. A literal that only has a value, and the language or data type are not declared, will compact to a JSON string or number.

Instead it should be possible to have the resource compact to:
{"@id": "uri"}
And the literal compact to:
{"@value": "value"}

[azaroth42]

Per call, my preference is a new keyword because:

• It's less confusing than adding further exceptions to the meaning of @type
• It's orthogonal (in my view) to @type and the other context keywords
• Having a developer required to make multiple calls to accomplish something that could be declared seems to go against the priority of constituencies.

As a strawperson, in a context I would like to declare:

{
  "value": {"@id": "rdfs:value", "@compact": "@dict", "@container": "@set},
  "relation": {"@id": "dc:relation", "@type": "@id", "@compact": "@dict", "@container": "@set"}
}

Which would force the following input:

{
  "@id": "http://example.net/instance/1",
  "value": 6,
  "relation": "http://example.net/instance/2"
}

To compact to:

[
  {
    "@id": "http://example.net/instance/1",
    "http://example.org/dc/relation": [
      {
        "@id": "http://example.net/instance/2"
      }
    ],
    "http://example.org/rdfs/value": [
      {
        "@value": 6
      }
    ]
  }
]

Which happens to be identical to the expanded form.

[gkellogg]

As I said on the call, this is really not necessary, as the context used for compacting a document is not also used for expanding that document (unless it happens to be included in the document itself, or provided using the expandContext option. In this sense, the use of @type is unambiguous.

There are reasonable differences on what the value of @type should be to signal this. IMHO, @none is perfectly consistent with the intuitive meaning of none, regardless of its use elsewhere. Introducing a new keyword, such as @dict is not unreasonable, but not really necessary either.

This would make the context usage like the following:

{
  "value": {"@id": "rdfs:value", "@type": "@none", "@container": "@set"},
  "relation": {"@id": "dc:relation", "@type": "@none", "@container": "@set"}
}

and would yield the same results as @azaroth42 indicated. Note that when re-expanding the document, no values would be strings if compacted using this context. We should decide what to do if they are, however, and here I would say that they be treated as simple values, but that is not significant for the use case.

[azaroth42]

@gkellogg In your approach, how do you distinguish between a string literal and a resource's URI and thus whether to use @id or @value?

e.g.

{
  "@context": {
    "value": {"@id": "rdfs:value", "@type": "@none", "@container": "@set"},
    "relation": {"@id": "dc:relation", "@type": "@none", "@container": "@set"}
  },
  "@id": "http://example.net/instance/1",
  "value": "http://example.net/instance/2",
  "relation": "http://example.net/instance/2"
}

How would the processor know what to do with this data?

[gkellogg]

Compaction always starts from the expanded form, so there's no confusion. The steps are the following:

1. Call the compact API.
2. Expand the input document, possibly using expand API.
   1.1. Expand the input document using the http://www.w3.org/ns/json-ld#context link relation, if present, and options possibly including expandContext.
3. Compact the expanded document using the provided context.

In the expansion phase, it presumes that the included or specified context has term definitions to make the use of string values unambiguous. When compacting, you have the term definition that prevents it from going back to a simple string representation.

It seems that you think that a document might use a context with such a term definition and have string values that should be treated differently. That's not really how the whole round-tripping was intended, so I don't see a need to complicate a term definition so it can serve multiple roles, when what we have now works as intended.

In summary, we shouldn't see a document such as you present, as it's inconsistent with the way the term definitions are specified, which could be true for many different combinations of data.

[azaroth42]

Okay, I see :) So if you had value with @type: @none in the context, then it would not be valid to have just a string, it would need to be a JSON object that gave a datatype or class. Thus setting @type to @none in the context is precisely correct -- the context is explicitly declaring that the relationship's object does not have a default interpretation and hence would require it to be in the expanded form.

👍 from me.

[azaroth42]

Defer, pending w3c/json-ld-syntax#77 discussion.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Defer api#33 until after discussion of disambiguation of the uses of @type as rdf:type or datatype of the JSON object

View the transcript

Rob Sanderson: link: #33
Rob Sanderson: next issue, not compact urls to string
… raised in CG, suggested to use @id and @value to avoid this. @gkellog suggested @none.
… because @none would go in the context, you are simply saying that object has no type declared in context
Ivan Herman: the point is we do have this issue of using @type differently than how those of us from rdf world think of rdf:type
… we need to be very, very clear about this.
Gregg Kellogg: the way to think about @type is more like datatype
… really comes down to question of how different this concept is from original intent of @type (rdf:type)
… @type @id says treat as is URI, @type @none just says there is no datatype so you can’t compact down to a string
… when we expand, do we default to something or do we raise error?
Rob Sanderson: in the data @type is how you express rdf:type
… we need to make obvious the aliasing of @type to type and explain in the primer
… in terms of error vs. default when expanding, I would favor an error
… picking (guessing) seems dangerous
Adam Soroka: we can get into confusion about there is not a @type vs none
Gregg Kellogg: when you expand a document and type is not specified default is treat them as simple literals
… equivalent to saying default rdf:type is xsd:string
Rob Sanderson: "value": {"@type": "@none"}
Rob Sanderson: "value": "string"
Rob Sanderson: "value": {"@id": "rdf:value"}
Rob Sanderson: if we had @type @none for value then if in the data value : string, would be treated as a string
Gregg Kellogg: if in the context, would mean value is alias for string, if in data, either treated as error or treated as string
Rob Sanderson: {"@context": {"value1": {"@id": "rdf:value", "@type": "@none"}, "value2": {"@id": "rdf:value"}} …
Rob Sanderson: “value1”: “string”, “value2: “string”}
Rob Sanderson: for the above example, both would be understood the same
Gregg Kellogg: or value1 would generate an error
Benjamin Young: want to make sure rest of us aren’t just become spectators on this
Adam Soroka: so in response to @BigBlueHat, let me offer my understanding
… so in rdf we distinguish between literals and strings
Simon Steyskal: -q
Adam Soroka: not the same in json-ld
… so in json-ld @type is doing several things at once
… so we keep adding more to what @type does, but it breaks down when moved into the rdf world
… so some uses of @type will add triples, some will not
… baked into the 2 different data models
… if you alias @type it aliases both for rdf:type and as datatype in the json-ld documents
… not good, but we are stuck with it, I think. So we need to document thoroughly
Rob Sanderson: seems 100% correct to me
Ivan Herman: yes, we are stuck with it, but nevertheless as a helping measure we could define a fixed alias and encouraging people to use alias differently
… down the line could become separate keys
… more than just a best practice, but also a temporizing solution
Gregg Kellogg: these issues came up in 1.0, but it’s good to mindful of the original json-ld which was find a way to understand your json as rdf
… so this is why we have context, and this is why we have to deal with URIs vs Strings
… we have discussed a default context (as a way to create default alias)
… does create an issue when compacting, because one of the aliases has to win out
… so round-tripping leads to these kinds of issues.
… we are restricted a bit on what we do for 1.1 (may be able to do more for 2.0)
Rob Sanderson: Thus {"@context": {"type": "@type", "@datatype": "@type"} ... } would allow people to use @datatype for data types, but compaction would always select one or the other for all situations
Rob Sanderson: so if we put aliases type and datatype, works for expansion, but would not roundtrip through compaction
… so maybe datatype has to more than just a context item
Gregg Kellogg: but it would break some compaction rules, so would require 1.1 being explicit
Rob Sanderson: are we ready to move forward? Or do we need more time
Ivan Herman: the latter
Jeff Mixter: I would like to mull this over more
Rob Sanderson: will make new issue about disambiguating different uses of @type
… will provide a framework for resolving issue
Gregg Kellogg: may take some time to resolve at f2f
Rob Sanderson: please add initial thoughts and then expect we may discuss in greater detail at f2f
Proposed resolution: Defer api#33 until after discussion of disambiguation of the uses of @type as rdf:type or datatype of the JSON object (Rob Sanderson)
Tim Cole: +1
Rob Sanderson: +1
Benjamin Young: +1
Ivan Herman: +1
Gregg Kellogg: +1
Adam Soroka: If LD isn’t about making the +1
Jeff Mixter: +1
Adam Soroka: +1
Simon Steyskal: +1
Resolution #3: Defer api#33 until after discussion of disambiguation of the uses of @type as rdf:type or datatype of the JSON object

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Use @type:@none to force compaction to generate object values ; Ivan and Adam will review for understandability {: #resolution12 .resolution}

View the transcript

Option to specify level of compaction for literals & resources
Rob Sanderson: ref: #33
Rob Sanderson: #33 (comment)
Gregg Kellogg: what happens if you see data that’s a string? Answer: you won’t.
… but the alg. has to do something.
… provide a way to compact a document that does IRI compaction (aka turn IRIs into terms/compact IRIs) probably to reduce the use of arrays so you don’ t use it unless you need it.
… so we would always have objects with @id and @value. If they were aliased, it would be that, etc, etc.
… so the question that Rob raised is what if you see an input that has @value that looks like a URI, and that has @type: none. What would happen?
… this wouldn’t happen, because you’d expand that makes this unambiguous. But what id you did?
… I would say that you’d probably treat these as strings.
Rob Sanderson: I agree
Adam Soroka: It seems that it’s a little surprising, but this should be explained clearly, since it can be counterintuitive.
Gregg Kellogg: and where does this go?
… it’s not really part of the syntax.
… that matters in compaction, but to an author, I don’t think that @none has an effect, because it only matters in context evaluation
… the syntax document leaves the rules to the API document
Ivan Herman: I would welcome this into the syntax document
… people don’t read the API document.
Gregg Kellogg: but it’s not useful to understand the syntax, but only the operation of the compaction
Ivan Herman: if there are ways to control compactions, I should know them in the API document
Adam Soroka: does this go in the primer?
Gregg Kellogg: when you’re reading an document, and you see an embedded context, you get the mental model of what expansion does. Similarly, when compacting, you get the idea of how to turn an ID into a string.
… you can understand the mental model.
Ivan Herman: where is that documented?
Gregg Kellogg: there’s an incomplete description in the syntax document, and a full description would make the syntax document even MORE complicated.
Adam Soroka: Can we put a note in somewhere?
Gregg Kellogg: we need a note for it now
Rob Sanderson: let’s see what the documentation looks like
Gregg Kellogg: agreed, and someone should read through it and see what’s missing.
Adam Soroka: ajs6f: +1 to responding to something concrete
Gregg Kellogg: framing is a different, since it embodies more.
Proposed resolution: Use @type:@none to force compaction to generate object values ; Ivan and Adam will review for understandability (Rob Sanderson)
Rob Sanderson: +1
Gregg Kellogg: +1
Jeff Mixter: +1
David Newbury: +1
Ivan Herman: +1
Adam Soroka: the primer should talk a lot about shapes.
Adam Soroka: +1
David I. Lehn: +1
Harold Solbrig: +1
Resolution #12: Use @type:@none to force compaction to generate object values ; Ivan and Adam will review for understandability {: #resolution12 .resolution}