Incorrect Usage of uid/@id in Implementation Best Practices

[sebbader]

The best practices state that Example 1 (JSON-LD) and Example 2 (turtle) are equivalent. I am wondering if I might miss something but if I translate the JSON-LD, my output looks different mainly on the subject position and the odrl:uid property.

Example 1:

{
     "@context": "http://www.w3.org/ns/odrl.jsonld",
     "@type": "Set",
     "uid": "http://example.com/policy:1010",
     "permission": [{
        "target": "http://example.com/asset:9898.movie",
        "action": "use"
     }]
}

Which I would translate to (please note the blank node at the root and the strings at the object positions):

@prefix odrl:  <http://www.w3.org/ns/odrl/2/> .

_:b  a                odrl:Set ;
  odrl:permission  [ odrl:action  "use" ;
                     odrl:target  "http://example.com/asset:9898.movie"   ] ;
  odrl:uid         "http://example.com/policy:1010"
.

but the Example 2 actually says (with a few adjustments to differing URIs):

@prefix odrl:  <http://www.w3.org/ns/odrl/2/> .

<http://example.com/policy:1010> a odrl:Set ;     
  odrl:permission [
    odrl:target <http://example.com/asset:9898.movie> ;
    odrl:action odrl:use
  ] .

Which in my view outlines the following issues:

• http://example.com/policy:1010 as the subject requires "@id": "http://example.com/policy:1010" instead of "uid": "http://example.com/policy:1010" in the JSON-LD.
• <#> odrl:action odrl:use . in Turtle needs a JSON-LD representation like "action": {"@id": "use"}

As I personally think that the Turtle representation of Example 2 is the right way (whatever right means), this brings me to two questions:

1. Why is odrl:uid mandatory? Isn't the intention rather to always have "@id" set in JSON-LD and thereby preventing blank nodes on the level of policies? If so, the constraint in the recommendation (section 2.1) needs to be formulated differently...
2. Shouldn't the JSON-LD example not rather look like this, even though being more ugly on the JSON-LD-side?

   {
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Set",
    "@id": "http://example.com/policy:1010",
    "permission": [{
       "target": { "@id": "http://example.com/asset:9898.movie" },
       "action": { "@id": "use" }
    }]
   }

Appreciate your feedback!

[vroddon]

Dear Sebastian, 1) I have just tried converting the JSON-LD serialization into Turtle (https://www.easyrdf.org/converter) and I got the expected result. 2) The uid field resorts to @id (you can see that in the context file https://www.w3.org/ns/odrl.jsonld)

Therefore, this is a expected result --whether desirable or not, can be discussed in https://github.com/w3c/odrl/issues/30

[sebbader]

@vroddon I lost track of this issue due to some other things in the last months, so sorry for the late reply.

I have just tried converting the JSON-LD serialization into Turtle (https://www.easyrdf.org/converter) and I got the expected result.

True, but the mapping of the "uid" to the JSON-LD key "@id" is not common practice. I am not sure if it's wrong, though. But if you translate the Turtle back to JSON-LD, the "odrl:uid" property won't appear anymore. So a roundtrip JSON-LD -> Turtle -> JSON-LD will lead to a different content.

In that sense is my initial example not correct, I missed the "uid"->"@id" mapping in the Context. But the issue is still valid, I think.

[vroddon]

Identifiers are a "built-in" in RDF, not in XML. I can't imagine any better form to transcode XML into RDF and vice-versa --this duality "uid/@id" is unavoidable, if we wan't to keep both RDF and XML. In any case, since we consider "uid" and "id" equivalent, there would be no "semantic" contradiction. Or did I miss an additional point?

[vroddon]

Closed until this is reported to be a problem.