fix: fix RDF triples example from Thing description json-ld 1.1

[ethieblin]

Hello,

We have noticed that the triples about the security definition were not present in the RDF example (https://www.w3.org/2019/wot/td#thing-description-json-ld-1-1-instance-to-rdf-dataset).

Using the https://www.w3.org/2019/wot/td/v1 context in the JSON-LD playground, we did not get exactly the same triples as our correction but the following:

<urn:dev:ops:32473-WoTLamp-1234> <https://www.w3.org/2019/wot/td#securityDefinitions> _:b0 .
_:b0 <https://www.w3.org/2019/wot/td#in> "header" .
_:b0 <https://www.w3.org/2019/wot/td#scheme> "basic" .

We figured there may be an issue with the context and we will try to propose a PR to fix it.

[vcharpenay]

it's unfortunate but security definition IDs resolve against the URI of the document, not the id of the TD. It would be more accurate to put <basic_sc> instead of <urn:dev:ops:32473-WoTLamp-1234/basic_sc> (which assumes the context overrides the base URI to the TD's id).

Thanks for spotting the change, though!

[wiresio]

@AndreaCimminoArriaga - FYI, since you also use a workaround for this in wot-jtd

[AndreaCimminoArriaga]

I'm not sure how this is going to be solved, just to add some personal experience to the conversation. When a TD is translated into triples the <basic_sc> can not be stored in Sail-based triple stores (RDF4j, GraphDB, etc.). This is a major problem since they require that URI to be absolute and not relative (as it is now). As workaround, what I did in wot-jtd, is leaving the relative address <basic_sc> . However, in the WoT directory implementation I'm forced to append an absolute URI (known as the base URI).

It would be really great if this issue could be fixed directly in the context providing an absolute URI. If the absolute URI of the basic_sc should be resolved using the id of the Thing, e.g., urn:dev:ops:32473-WoTLamp-1234/basic_sc, this is fine too. If I recall correctly however, in the spec, the way of resolving it is not clear.

[vcharpenay]

When a TD is translated into triples the <basic_sc> can not be stored in Sail-based triple stores (RDF4j, GraphDB, etc.).

How so? If the TD originates from a programmatic call to a Sail, it's not surprising the library throws an error because the source document is not known. Without source, relative URIs cannot be resolved. It's always possible to pass a base URI as a configuration argument, as far as i know, though.

Libraries that wouldn't fail when parsing relative URIs without base (Jena, for instance) just have a default base URI in their code base. This is not necessarily a good thing, since it injects erroneous information into an RDF dataset.

In any case, in your code (for a TDir or a TD processing library), you can pass the Thing's id as argument for the base URI but JSON-LD contexts don't allow base URIs relative to a JSON-LD object (unfortunately).

[AndreaCimminoArriaga]

I discovered this issue recently. As you mentioned Jena does not have this problem since it has a default base URI. For Sail I have to specifically add the base, since I'm injecting data using SPARQL I rely on the BASE statement and that does the work.

Anyway, now that I know that the base for the security should be the id, I think I will modify the code of the JTD so it automatically handles this issue.

[vcharpenay]

As far as I'm concerned, I wouldn't make it a requirement that the base be the Thing's id. In case there are several TDs with varying security configurations for the same Thing, one might want to keep the origin information about individual configurations (assume e.g. a default definition that resolves as a basic auth configuration with IRI http://example.org/td1/default but also a digest auth in another TD, with IRI http://example.org/td2/default). Generally speaking, a TD document is not the same as the Thing it describes.

Yet, the Thing's id can be used as a default base URI, why not. Regarding the content of this PR, the changes by @ethieblin can remain as is, then. @ethieblin could you maybe add the base URI declaration (@base) in the JSON-LD variant, so that the example is unambiguous?

{
  "@context": [
    "https://www.w3.org/2019/wot/td/v1",
    { "@base": "urn:dev:ops:32473-WoTLamp-1234" }
  ],
  "id": "urn:dev:ops:32473-WoTLamp-1234",
  "title": "MyLampThing",
  "securityDefinitions": {
      "basic_sc": {"scheme": "basic", "in":"header"}
  },
  "security": ["basic_sc"],
 ...
}

[Murloc6]

As far as I'm concerned, I wouldn't make it a requirement that the base be the Thing's id. In case there are several TDs with varying security configurations for the same Thing, one might want to keep the origin information about individual configurations (assume e.g. a default definition that resolves as a basic auth configuration with IRI http://example.org/td1/default but also a digest auth in another TD, with IRI http://example.org/td2/default). Generally speaking, a TD document is not the same as the Thing it describes.

Yet, the Thing's id can be used as a default base URI, why not. Regarding the content of this PR, the changes by @ethieblin can remain as is, then. @ethieblin could you maybe add the base URI declaration (@base) in the JSON-LD variant, so that the example is unambiguous?

{
  "@context": [
    "https://www.w3.org/2019/wot/td/v1",
    { "@base": "urn:dev:ops:32473-WoTLamp-1234" }
  ],
  "id": "urn:dev:ops:32473-WoTLamp-1234",
  "title": "MyLampThing",
  "securityDefinitions": {
      "basic_sc": {"scheme": "basic", "in":"header"}
  },
  "security": ["basic_sc"],
 ...
}

Thanks for the suggestion, we amended the commit to implement the @base into the context.

[sebastiankb]

from today's TD call:

• its unclear what is the status of this PR
• @vcharpenay can you have a look if we can merge this PR?

[vcharpenay]

the PR is almost ready for merging. It depends on another recently created PR, though (#1289) because that PR slightly changes security definition triples.

[sebastiankb]

@vcharpenay many thanks. If I understand correctly, when #1289 is merged we can merge this one, right?

[sebastiankb]

from today's TD call:

• this PR is not needed anymore since PR Add 'instantiation' property to security scheme #1289 covers this as well
• going to close this PR