type coercion: coerce node types

[lukasheinrich]

I think it would be interesting to add type coercion also to node objects in JSON-LD. Consider a document like

{
    "@context": {
        "@version": 1.1,
        "ex": "http://example.org/",
        "things": {"@id":"ex:thing"}
    },
    "things": [
      {"@type": "ex:typeofthing","ex:attribute":"value1"},
      {"@type": "ex:typeofthing","ex:attribute":"value2"},
      {"@type": "ex:typeofthing","ex:attribute":"value3"}
    ]
}

it would be nice it I could specify in the context what the "@type" of each node referred to by the predicate "ex:thing" is in order to reduce repetitiveness. Similar how I can do it for terms pointing to literals.

{
    "@context": {
        "@version": 1.1,
        "ex": "http://example.org/",
        "things": {"@id":"ex:thing", "@type": "ex:typeofthing"}
    },
    "things": [
      {"ex:attribute":"value1"},
      {"ex:attribute":"value2"},
      {"ex:attribute":"value3"}
    ]
}

Right now, @type seems to just be ignored when the object in the triple is not a literal -- so perhaps it is straight forward to add?

{
    "@context": {
        "@version": 1.1,
        "ex": "http://example.org/",
        "ex:term": {"@type":"ex:literaltype"}
    },
	"ex:term": "literalvalue"
}

expands to

[
  {
    "http://example.org/term": [
      {
        "@type": "http://example.org/literaltype",
        "@value": "literalvalue"
      }
    ]
  }
]

while

{
    "@context": {
        "@version": 1.1,
        "ex": "http://example.org/",
        "ex:term": {"@type":"ex:nodetype"}
    },
    "ex:term": {"@id":"ex:anode"}
}

expands to:

[
  {
    "http://example.org/term": [
      {
        "@id": "http://example.org/anode"
      }
    ]
  }
]

[gkellogg]

You are basically proposing a means of inserting data from the context into the JSON-LD document. This was considered in json-ld/json-ld.org#426 using an @content to a term definition; as this is pretty far outside the scope of what the context is intended for, it was ultimately dropped.

The problem with re-interpreting @type in a content definition is that it is also used for matching value objects having that datatype, and there is really no way to know how it is intended to be used differently for a node object.

[azaroth42]

There is an editorial note here that "type coercion" language in the spec is not actually what people consider as type coercion in programming. We might forestall some of these issues by changing the description of the feature.

And otherwise, +1 to close wontfix.

[gkellogg]

There is an editorial note here that "type coercion" language in the spec is not actually what people consider as type coercion in programming. We might forestall some of these issues by changing the description of the feature.

IMO, "type coercion" is correct, as it allows an integer 1 to be coerced to a float using "@type": "xsd:float". What it does not do is allow node objects to be "coerced" to some specific rdf:type, which seems to catch people up. In what sense is this not what type coercion in programming relates to? Without the ability to assign to typed variables, I'm not sure how else you might affect coercion. Do you have alternate wording in mind?

[iherman]

There is also a slippery slope here, insofar as this simply duplicates an RDFS feature; after all, this type of deduction is exactly what rdfs:range is for: deducing the type of an object based on the property. Do we really want to open this can of worms? (Why would we stop here, why not going all the way and introduce things for domains, for example...) This would certainly not be a 1.1 change...

I propose to close with wontfix.

[lukasheinrich]

so what is the proposed way to process a object without type information? I guess the RDF way would be to use either RDFS or OWL to reason about the graph and infer the new triple <node-uri> <type> <type-uri> but that seems a bit heavy-handed (and somewhat far removed from general users, who JSON-LD tries to reach). I agree adding the possibility of adding generic triples @content might be tricky, but for things like indices JSON-LD already inserts data into the expanded object (i.e. @index)

[gkellogg]

@iherman this is simply a 1.0 feature that allows would would have been something like ^^xsd:dateTime in Turtle, to be placed in the term definition in a JSON-LD context. This allows a term such as date to take a string value, which would expand to a value object containing an appropriate @type.

The "fix" which is asked for is to simply ensure that other places that make use of this feature reference the appropriate definition.

If you find the "type coercion" terminology from 1.0 confusing, we could propose renaming it.

[iherman]

@gkellogg

@iherman this is simply a 1.0 feature that allows would would have been something like ^^xsd:dateTime in Turtle, to be placed in the term definition in a JSON-LD context.

Yeah. I now realize (I forgot) that JSON-LD, sort of, mashes up two notions: an RDF datatype and the type in the sense of belonging to an RDF Class. I may not like this, but that is water under the bridge now, I guess... However, I do accept that, in this sense, the original proposal is just a logical extension of a possibility that is already there.

I indeed find the "type coercion" terminology confusing indeed. Whilst it makes some sense for a datatype, it is really not appropriate when I think of it as an object belonging to a class. I am not sure what to replace it; something around a neutral terminology like "setting the type" is probably better if it fits, editorially, to the context.

[azaroth42]

Closing, won't fix.
Rationale: Contexts must not add additional triples to the data.

WG Resolution: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-07-27-json-ld#section2-1