Treat reverse term definitions more like regular definitions

[niklasl]

There is a problem with the following rule in the JSON-LD Syntax, section "B.7 Context Definitions":

If an expanded term definition has an @reverse member, @id, @type, and @language are not allowed. If an @container member exists, its value must be null or @index.

The definition should allow "@container": "@set", to tell a compaction mechanism to always use an array? And/or use "@type": "@id" to allow for use of IRIs as strings.

Although the specified compaction doesn't make use of that (since it only uses reverses if it's explicitly given in the expanded form), another compaction mechanism (e.g. using repeated re-embedding) could make use of @container or @type here. So I'm not sure if it's good to disallow this syntactically...

An example of desired usage:

{
    "@context": {
        "@vocab": "http://schema.org/",
        "instances": {"@reverse": "instanceOf", "@container": "@set"}
    },
    "@id": "/work/123",
    "@type": "CreativeWork",
    "instances": [
        {
            "@id": "/instance/123/a",
            "@type": "CreativeWork"
        },
        {
            "@id": "/instance/123/b",
            "@type": "CreativeWork"
        }
    ]
}

(I.e. declaratively state that "instances" is an array even if it only contains one object.)

Also, as noted by Markus:

Reverse properties are always of type @id and will thus automatically
compact to strings if there are no other properties. Do you want to be able
to turn that automatic compaction off?

I figure the data would be unpredictable otherwise. This should be under the control of the context author, via the regular @container mechanism.

[lanthaler]

The definition should allow "@container": "@set", to tell a compaction mechanism to always use an array? And/or use "@type": "@id" to allow for use of IRIs as strings.

As already mentioned in an email, the change to support "@container": "@set" would be trivial:

• Compaction 7.2.2.1.1 would need to take the property's container into consideration
• Create Term Definition 10.5 would also need to allow @set

I think we can threat that as a bug fix without going through another LC.

Also, as noted by Markus:

Reverse properties are always of type @id and will thus automatically
compact to strings if there are no other properties. Do you want to be able
to turn that automatic compaction off?

I figure the data would be unpredictable otherwise. This should be under the control of the context author, via the regular @container mechanism.

You probably meant @type mechanism. Anyway, would this mean that @type: @id is set implicitly just in one direction, i.e., expansion and not compaction? Or would the following data result in an error because the subject is a literal because it is not implicitly typed to @id anymore?

{
    "@context": {
        "@vocab": "http://schema.org/",
        "instance": { "@reverse": "instanceOf" }
    },
    "@id": "/work/123",
    "instance": "not-an-iri-anymore-but-a-literal?"
}

[lanthaler]

PROPOSAL 1: Allow "@container": "@set" for reverse properties

The required spec changes are:

• Update grammar
• Compaction algorithm step 7.2.2.1.1 would need to take the property's container into consideration
• Create Term Definition algorithm step 10.5 would also need to allow @set

PROPOSAL 2: Remove the @type restriction for reverse properties. This also means that a reverse property won't be implicitly type-coerced to @id anymore.

The required spec changes are:

• Update grammar
• Create Term Definition algorithm step 10.1 would need to allow @type
• Create Term Definition algorithm step 10.4 would need to be modified to handle @type. Since this duplicates step 15 we should move step 15 before step 10 and remove 10.4.

[gkellogg]

PROPOSAL 1: +1, presuming that the group agrees that it is a clarification of an ambiguity.

I don't really get PROPOSAL 2; if this reverses subject and object, then the object certainly must be an IRI or BNode, and there's no way to specify the subject as being anything other than an IRI or BNode, so how does this actually apply?

[lanthaler]

Yes, that’s right. If the value of a reverse property is not a node but a literal, an error will be thrown. The reason to remove the implicit type-coercion to @id is to allow a user to control the shape of the data in compaction. Without that, “node references” will be compacted to strings and nodes with properties other than @id will be objects. So proposal 2 does nothing else than allowing the user to decide whether node references should be compacted to strings or not. The effect is that you have to specify @type: @id if you want to use strings, just as with normal properties. Is this any clearer? :-)

[gkellogg]

Okay, +1 to PROPOSAL 2, that makes sense.

[niklasl]

Thanks Markus! That's precisely what I'm after.

PROPOSAL 1: +1
PROPOSAL 2: +1

[dlongley]

PROPOSAL 1: +1
PROPOSAL 2: +1

[lanthaler]

RESOLVED: Allow "@container": "@set" for reverse properties.

RESOLVED: Remove the @type restriction for reverse properties. This also means that a reverse property won't be implicitly type-coerced to @id anymore.