Scoping context based on the @type

[mitar]

Currently, for JSON data we have, I have to put @contexts all around the JSON to scope properties:

{
    "@context": {
        "@base": "http://127.0.0.1:8000/api/v2/node/",
        "@vocab": "http://127.0.0.1:8000/api/v2/node/?format=vocab#"
    },
    "@type": "Node",
    "@id": "000c3d9d-5d7c-492a-8d3b-bb8b922ae35f",
    "config": {
        "core.location": {
            "@context": {
                "@base": "_:config/core.location/",
                "@vocab": "http://127.0.0.1:8000/api/v2/node/?format=vocab#config/core.location/"
            },
            "@id": "123",
            "@type": "Location",
            "timezone": "Europe/Ljubljana",
            "address": "San Juan, Puerto Rico",
            "city": "Ljubljana",
            "country": "SI",
            "geolocation": {
                "@context": "http://geojson.org/geojson-ld/geojson-context.jsonld",
                "type": "Point",
                "coordinates": [
                    -66.073756,
                    18.378287
                ]
            },
            "altitude": 0.0
        },
        "core.project": {
            "@context": {
                "@base": "_:config/core.project/",
                "@vocab": "http://127.0.0.1:8000/api/v2/node/?format=vocab#config/core.project/"
            },
            "@id": "444",
            "@type": "Project",
            "project": "http://127.0.0.1:8000/api/v2/project/2"
        }
    }
}

It would be great if I could somehow @vocab (or @context) itself would be scoped based on the value of @type, similarly to what I have to do currently manually. Ideally, JSON-LD would then be something like:

{
    "@context": {
        "@base": "http://127.0.0.1:8000/api/v2/node/",
        "@vocab": "http://127.0.0.1:8000/api/v2/node/?format=vocab#"
    },
    "@type": "Node",
    "@id": "000c3d9d-5d7c-492a-8d3b-bb8b922ae35f",
    "config": {
        "core.location": {
            "@id": "_:config/core.location/123",
            "@type": "config/core.location/Location",
            "timezone": "Europe/Ljubljana",
            "address": "San Juan, Puerto Rico",
            "city": "Ljubljana",
            "country": "SI",
            "geolocation": {
                "@context": "http://geojson.org/geojson-ld/geojson-context.jsonld",
                "type": "Point",
                "coordinates": [
                    -66.073756,
                    18.378287
                ]
            },
            "altitude": 0.0
        },
        "core.project": {
            "@id": "_:config/core.project/444",
            "@type": "config/core.project/Project",
            "project": "http://127.0.0.1:8000/api/v2/project/2"
        }
    }
}

And all definitions of properties would stay exactly the same as in the initial JSON at the top.

[niklasl]

👍 Yes, if nested contexts are to be supported, I think connecting them to @type is a good approach. Expectation on shape/terms is commonly connected to @type.

The alternative (as I've seen it) – to tie nested contexts to specific properties (links) – would risk an increase in fragmentation (e.g. if a Person used title for foaf:title when linked to with dc:creator but not dc:contributor).

[niklasl]

I should probably balance my opinion by saying that I think both alternatives have merit. A possible solution is to support term-controlled contexts in both cases (i.e. apply it both for terms with local context used as predicates, and for those used as values of @type).

(I guess the harder question is whether the local context would extend the base or not (I'd wager for extension by default).)

[dlongley]

👍 to adding both @type and property scoped contexts.

There's also an interesting JSON transformation tool worth mentioning here that could be combined with some of these future JSON-LD features (potentially useful for framing as well): https://github.com/bazaarvoice/jolt

[gkellogg]

In addition to #247, #262, see also #315.

[azaroth42]

A use case for this that would solve a significant pain point in the cultural heritage domain is the over-reliance on domain and range specific predicates, and using type based contexts to reduce them back to a smaller and more understandable set of JSON keys.

For example, in CIDOC-CRM there are several pairs of hasPart/partOf predicates based on the domain. These could be collapsed down to part and partOf per class without ambiguity as the domains and ranges do not overlap. In English:

• Time Periods consist of / form part of other Time Periods
• Time Spans fall within / contain other Time Spans [don't ask about the difference with above]
• Information objects are composed of / form part of other Information Objects
• Things are composed of / form part of other Things
• Places fall within / contain other Places
• Types define typical wholes for /define typical parts of other Types
• Groups have current or former member of / ... Actors, including other Groups
• ...

Thus it would be great to have a context that allowed part to be used consistently in the JSON-LD and map to the appropriate predicate in RDF. Currently we have, for example:

{
  "@context": "https://lod.shared-canvas.org/ns/context/1/full.jsonld", 
  "id": "https://lod.shared-canvas.org/example/activity/0", 
  "type": "Activity", 
  "label": "Example Auction", 
  "consists_of": {
    "id": "https://lod.shared-canvas.org/example/activity/0/part/1", 
    "type": "Activity", 
    "label": "Example Auction of Lot"
  }
}

Which expands to this.

And:

{
  "@context": "https://lod.shared-canvas.org/ns/context/1/full.jsonld", 
  "id": "https://lod.shared-canvas.org/example/object/1", 
  "type": "ManMadeObject", 
  "label": "Example Painting", 
  "part": {
    "id": "https://lod.shared-canvas.org/example/object/1/part/1", 
    "type": "PhysicalObject", 
    "label": "Canvas Support"
  }
}

which expands to this (some triples elided here from the full example).

If we could associated part with consists_of when the type is Activity, and with composed_of (currently mapped to part) when the type is ManMadeObject all museum developers' lives would be greatly enriched :)

[Edit: And my life, as I got the wholes/parts around the wrong way in the list first time round!]

[azaroth42]

I think there are a few potential issues to be addressed:

• If a resource has multiple types, and their scoped contexts are in conflict, how is the conflict resolved? For example, if there was a ManMadeObject that was also an Activity, which predicate does part resolve to? And inversely, if the same predicate has two different mappings in two different classes, which of the keys will be used in the serialization? (Thanks to @gkellogg for this one)
• If there is a conflict between predicate and class, how is that conflict resolved? For example, if the relationship between Activity and ManMadeObject (being used_specific_object fwiw) also asserted what part should be interpreted as, which takes precedence?
• Without re-encoding the entire ontology in the context, how can subclasses exhibit the same behavior as their ancestors?

Towards the first, if there is a conflict, then it seems like there are two options:

1. Pick one of the options at random. This seems undesirable as a source of heisenbug frustration.
2. Fall back to the prefix:predicate or predicate URL. This (to me) is at least consistent and gives a much clearer indication that there is a conflict. It would also be consistent with the behavior of mixing incompatible types in a language map.

Towards the second ... same as the first? Or use the predicate? This seems like a "don't do that then" moment, to me.

And the last ... re-expressing the differences for every class seems like the only way to go. This has the (IMO) beneficial side effect that context designers will try harder to put everything at the 1.0 compatible top level and only express the differences in scopes.

And as a syntactic proposal, the sub-context could live within the definition of the class's term in the context, and the processor then checks the mappings for both the predicate and the class (conflict resolution as discussed above).

For example:

{
  "@context": { 
  "ns": "http://example.org/ns/",
  "Activity": {
    "@id": "ns:E7_Activity",
    "@type": "@id",
    "@context": {
      "part": {
        "@id": "ns:P9_consists_of",
        "@type": "@id"
      }
    }
  },
  "ManMadeObject": {
    "@id": "ns:E22_Man-Made_Object",
    "@type": "@id",
    "@context": {
      "part": {
        "@id": "ns:P46_is_composed_of",
        "@type": "@id"
      }
    }
  }
  },
  "@id": "http://example.com/myActivity",
  "@type": "Activity",
  "part": [ { ... further sub-activities ... } ],
  "used_specific_object": {
    "@id": "http://example.com/myObject",
    "@type": "ManMadeObject",
    "part": [ { ... further sub-objects ... } ]
  }
}