Make root object's @id the default base URI

[vcharpenay]

Here is a JSON-LD document that looks more or less like a Thing Description, a spec being developed at the W3C for the Web of Things. A Thing Description basically provides meta-data for 'Things' (here, a sensor) and links to their properties (e.g. a temperature value).

Properties must be uniquely identified, e.g. for access control on the sensor device. Ideally, the temperature property in this example would be identified by example://mysensor/wot, i.e. relatively to the @id of the sensor. I believe there is no way to achieve this with the current JSON-LD 1.1 spec.

{
  "@context": { "iot": "iotschema.org/" },
  "@id": "example://mysensor",
  "@type": "iot:Sensor",
  "properties": [
    {
      "@id": "temp",
      "@type": "iot:Temperature",
      "href": "coap://192.168.2.5/temp/val"
    }
  ]
}

This issue relates to some extent to #488, where it has been proposed to allow @vocab: @base in the context. I could imagine a similar solution here, by defining @base: @id (or @vocab: @id) to make the root object's @id the default base URI.

[vcharpenay]

In this example, it might also be worth mentioning that coap://192.168.2.5/temp/val cannot exactly be used as an identifier for the property. First, the two entities are semantically different: example://mysensor/wot is the temperature itself, while coap://192.168.2.5/temp/val is a measurement of the temperature value at a given point in time. But more importantly, the same temperature could be accessed via different resources (e.g. for CoAP, MQTT, HTTP or WebSocket, each with its own URI) while aspects like access control should be configured at the property level and not for individual Web resources.

[gkellogg]

This was discussed on the 2018-03-12 call. Adding another mechanism on @base or @vocab to tie them to @id is quite outside the current scope of the spec, and also incompatible with other RDF serialization formats, such as Turtle. As @iherman notes, sometimes blank nodes are necessary, and solve such use cases.

In this case, I think that @base might work, and define your Thing Description with that base, you can then have other @id values relative to that document base.