Support JSON-LD

[riannella]

We will support JSON-LD serialisation (not current JSON as in V2.1) as close as possible to ODRL Ontology. Update spec. required.

[riannella]

See email thread starting here: https://lists.w3.org/Archives/Public/public-poe-wg/2016Oct/0020.html

[riannella]

Now that we will support JSON-LD, does that mean we don't have to define our own JSON Schema as it is auto-generated from the ODRL Ontology?

[iherman]

Now that we will support JSON-LD, does that mean we don't have to define our own JSON Schema as it is auto-generated from the ODRL Ontology?

I indeed do not think we should define a JSON Schema. I believe, apart from what we already do in the information model document[1], we have to define a JSON-LD @context file that maps the JSON-LD to the RDF vocabulary and we may define, informally, JSON-LD Frames that define a preferred way of expressing things in JSON-LD (and that should reflect the way all the examples are in the info. model document.

At least this is the way the Anno WG did it, see[2].

Ivan

1. http://w3c.github.io/poe/model/ http://w3c.github.io/poe/model/
2. https://www.w3.org/TR/annotation-vocab/#json-ld-frames

[stuartmyles]

But wouldn't this same logic apply to the XML encoding too? Why not just auto-generate XML from the ODRL Ontology?

On the other hand, don't we need an JSON schema for people who don't care about (or don't like or have never heard of) RDF?

Regards,

Stuart

On Thu, Dec 8, 2016 at 9:18 AM, Ivan Herman notifications@github.com wrote:

Now that we will support JSON-LD, does that mean we don't have to define our own JSON Schema as it is auto-generated from the ODRL Ontology?

I indeed do not think we should define a JSON Schema. I believe, apart from what we already do in the information model document[1], we have to define a JSON-LD @context file that maps the JSON-LD to the RDF vocabulary and we may define, informally, JSON-LD Frames that define a preferred way of expressing things in JSON-LD (and that should reflect the way all the examples are in the info. model document.

At least this is the way the Anno WG did it, see[2].

Ivan

1. http://w3c.github.io/poe/model/ http://w3c.github.io/poe/model/
2. https://www.w3.org/TR/annotation-vocab/#json-ld-frames

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/46#issuecomment-265750248, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwBf_E-fTUjGDYI0f1tX5uvbUkbhmUoks5rGBHKgaJpZM4KZWR0 .

[iherman]

@stuartmyles, there are some major differences between RDF/XML and JSON-LD.

I believe it is possible to come up with an encoding of the model that is acceptable for JSON users who are not RDF users. JSON-LD has been defined with that goal in mind. It is not perfect, but I believe it goes a long way in this direction. Several WG-s have done this (Social Web, Annotation, even the CSV on the Web).

RDF/XML is and remains problematic even for XML users. There is no equivalent to the JSON-LD frames that would allow to use some sort of an RDF/XML dialect and. primarily, there is no equivalent to the JSON-LD @context notion that can hide most of the features that irritate non-RDF users (usage of various namespaces, for example).

[riannella]

I think @stuartmyles was talking about auto-generating the XML Schema from the Ontology? This never works in practice, as you end up with a convoluted and crazy XML Schema design. Hand crafting is the only way....yeah for me !

As for the auto-generation of the RDF/XML ontology from the turtle ontology, I am waiting on @nevali to update the script 👍

[iherman]

I think @stuartmyles https://github.com/stuartmyles was talking about auto-generating the XML Schema from the Ontology? This never works in practice, as you end up with a convoluted and crazy XML Schema design. Hand crafting is the only way....yeah for me !

Oops, my apologies. And XML Schema being very different from an OWL Ontology I tend to agree that relying on some automatism may be an issue.

As for the auto-generation of the RDF/XML ontology from the turtle ontology, I am waiting on @nevali https://github.com/nevali to update the script 👍

The question which is still open to me is whether we would keep the XML serialization on the agenda at all...

[riannella]

We still have XML implementations. When we asked the community in October, both Associated Press and Reuters News said they will use the XML encoding.

[iherman]

On 13 Dec 2016, at 14:03, Renato Iannella notifications@github.com wrote:

We still have XML implementations. When we asked the community in October, both Associated Press and Reuters News said they will use the XML encoding.

O.k. (But that is another discussion then; it should certainly not be RDF/XML.)

[stuartmyles]

Yes - I admit, I raised the question of auto-generating XML from the Ontology, to illustrate why I think auto-generating the JSON from the Ontology is also not a good idea.

I don't seriously think that we should auto-generate either XML or JSON. In both cases, the auto-generating the schema will result in ugly documents, Fine for people who never plan to work with the formats directly (i.e. those who only like the RDF data model but are indifferent to how it is expressed). But for people who only care about their preferred format (XML or JSON) then they are going to be put off by the details of the auto-generated encoding. And, worst case, create their own. This, for example, is what happened with the PRISM Rights Expression Language: they liked the ODRL data model, but decided to create their own XML encoding, because they don't like some of the details of the ODRL 2.1 encoding. See, for example, http://www.prismstandard.org/specifications/3.1/Draft_Rights_Summary_Guide_3.1.htm#_Toc406232056

As Renato says, there are already implementations of ODRL in both XML and JSON. Now, we can't make an omelette without breaking a few eggs. And, I'm not under the illusion that what we will end up with is exactly the same thing as ODRL 2.1. But I think this group should decide on purpose whether they want to specify the XML and JSON encodings of the ODRL (POE) data model. Or whether we are content for others to take the data model and make up their own encodings, which is what I predict will happen, if POE doesn't specify a JSON encoding.

Regards,

Stuart

On Tue, Dec 13, 2016 at 8:56 AM, Ivan Herman notifications@github.com wrote:

On 13 Dec 2016, at 14:03, Renato Iannella notifications@github.com wrote:

We still have XML implementations. When we asked the community in October, both Associated Press and Reuters News said they will use the XML encoding.

O.k. (But that is another discussion then; it should certainly not be RDF/XML.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/46#issuecomment-266744347, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwBfzp_ilISkIRtiU9_xdqgsy4_vnRgks5rHqP1gaJpZM4KZWR0 .

[Jimflip]

Hi

I think this has been said before, but to just to clarify and support the opinion. The JSON representation should be the JSON-LD simply with the @context removed. We define and provide the @context which will give us a representation in JSON that we agree on.

If people define their own JSON representation that is their choice, but with the semantics removed and a different representation then its basically not interoperable. They could provide something like an R2RML mapping back to JSON-LD or RDF from their JSON format, but basically thats not really relevant to us.

I suspect there is concern that a JSON-LD object with the @context removed is problematic? If so lets break down what exactly the perceived issues are.

Thanks, James.

On 14 Dec 2016, at 14:15, stuartmyles notifications@github.com wrote:

Yes - I admit, I raised the question of auto-generating XML from the Ontology, to illustrate why I think auto-generating the JSON from the Ontology is also not a good idea.

I don't seriously think that we should auto-generate either XML or JSON. In both cases, the auto-generating the schema will result in ugly documents, Fine for people who never plan to work with the formats directly (i.e. those who only like the RDF data model but are indifferent to how it is expressed). But for people who only care about their preferred format (XML or JSON) then they are going to be put off by the details of the auto-generated encoding. And, worst case, create their own. This, for example, is what happened with the PRISM Rights Expression Language: they liked the ODRL data model, but decided to create their own XML encoding, because they don't like some of the details of the ODRL 2.1 encoding. See, for example, http://www.prismstandard.org/specifications/3.1/Draft_Rights_Summary_Guide_3.1.htm#_Toc406232056

As Renato says, there are already implementations of ODRL in both XML and JSON. Now, we can't make an omelette without breaking a few eggs. And, I'm not under the illusion that what we will end up with is exactly the same thing as ODRL 2.1. But I think this group should decide on purpose whether they want to specify the XML and JSON encodings of the ODRL (POE) data model. Or whether we are content for others to take the data model and make up their own encodings, which is what I predict will happen, if POE doesn't specify a JSON encoding.

Regards,

Stuart

On Tue, Dec 13, 2016 at 8:56 AM, Ivan Herman notifications@github.com wrote:

On 13 Dec 2016, at 14:03, Renato Iannella notifications@github.com wrote:

We still have XML implementations. When we asked the community in October, both Associated Press and Reuters News said they will use the XML encoding.

O.k. (But that is another discussion then; it should certainly not be RDF/XML.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/46#issuecomment-266744347, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwBfzp_ilISkIRtiU9_xdqgsy4_vnRgks5rHqP1gaJpZM4KZWR0 .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/46#issuecomment-267043875, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIwzSKPXn8EJyVfsmDCKs47iJZQ4Vzzks5rH_nvgaJpZM4KZWR0.

[stuartmyles]

The JSON representation should be the JSON-LD simply with the @context removed.

Yes, I agree with this,

But the suggestion is now that we don't need to even have a specific JSON representation. Instead that we simply generate JSON (or JSON-LD) from the ODRL Ontology. My view is that, if we go down this path - not specifying "here's the JSON syntax" - then other people will craft their own.

Regards,

Stuart

On Wed, Dec 14, 2016 at 9:45 AM, James Birmingham notifications@github.com wrote:

Hi

I think this has been said before, but to just to clarify and support the opinion. The JSON representation should be the JSON-LD simply with the @context removed. We define and provide the @context which will give us a representation in JSON that we agree on.

If people define their own JSON representation that is their choice, but with the semantics removed and a different representation then its basically not interoperable. They could provide something like an R2RML mapping back to JSON-LD or RDF from their JSON format, but basically thats not really relevant to us.

I suspect there is concern that a JSON-LD object with the @context removed is problematic? If so lets break down what exactly the perceived issues are.

Thanks, James.

On 14 Dec 2016, at 14:15, stuartmyles notifications@github.com wrote:

Yes - I admit, I raised the question of auto-generating XML from the Ontology, to illustrate why I think auto-generating the JSON from the Ontology is also not a good idea.

I don't seriously think that we should auto-generate either XML or JSON. In both cases, the auto-generating the schema will result in ugly documents, Fine for people who never plan to work with the formats directly (i.e. those who only like the RDF data model but are indifferent to how it is expressed). But for people who only care about their preferred format (XML or JSON) then they are going to be put off by the details of the auto-generated encoding. And, worst case, create their own. This, for example, is what happened with the PRISM Rights Expression Language: they liked the ODRL data model, but decided to create their own XML encoding, because they don't like some of the details of the ODRL 2.1 encoding. See, for example, http://www.prismstandard.org/specifications/3.1/Draft_ Rights_Summary_Guide_3.1.htm#_Toc406232056

As Renato says, there are already implementations of ODRL in both XML and JSON. Now, we can't make an omelette without breaking a few eggs. And, I'm not under the illusion that what we will end up with is exactly the same thing as ODRL 2.1. But I think this group should decide on purpose whether they want to specify the XML and JSON encodings of the ODRL (POE) data model. Or whether we are content for others to take the data model and make up their own encodings, which is what I predict will happen, if POE doesn't specify a JSON encoding.

Regards,

Stuart

On Tue, Dec 13, 2016 at 8:56 AM, Ivan Herman notifications@github.com wrote:

On 13 Dec 2016, at 14:03, Renato Iannella notifications@github.com wrote:

We still have XML implementations. When we asked the community in October, both Associated Press and Reuters News said they will use the XML encoding.

O.k. (But that is another discussion then; it should certainly not be RDF/XML.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/46#issuecomment-266744347, or mute the thread https://github.com/notifications/unsubscribe- auth/ADwBfzp_ilISkIRtiU9_xdqgsy4_vnRgks5rHqP1gaJpZM4KZWR0 .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https://github.com/w3c/poe/issues/46#issuecomment-267043875>, or mute the thread https://github.com/notifications/unsubscribe-auth/ AAIwzSKPXn8EJyVfsmDCKs47iJZQ4Vzzks5rH_nvgaJpZM4KZWR0.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/46#issuecomment-267051570, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwBfxkNLr2x6HOSqv9_ikLbQEsgzIBrks5rIAEGgaJpZM4KZWR0 .

[iherman]

To add what @Jimflip said: please look at

• the Web Annotation Model document, that defines the annotation structures in JSON that happens to be JSON-LD (it does include a single @context)
• the JSON-LD @context is defined in the separate (RDF) vocabulary document, mapping the Annotation structures to RDF (if needed)
• we also have a JSON-LD frame that allows any valid JSON-LD encoding of the RDF vocabulary be represented the way it is defined in the Annotation Model document.

Note that the vocabulary (ie, the ontology) itself has been hand-crafted in Turtle. One of the exit criteria of that document is to prove that the @context we define maps the JSON version onto an RDF graph that is indeed valid per the ontology.

We have a number of implementers who use the JSON encoding as defined in the Annotation Model document, and they do not care about RDF. For them, that document defines a JSON encoding. Others care about the RDF aspect, and they use it accordingly.

I believe that approach (also used by the Social Web WG) can be reproduced by the POE work (and may already been done in our model document, in fact).

As for the remark of @stuartmyles : the JSON encoding is necessary, I believe, ie, it should not be generated by the ontology because there are different ways to represent a graph in JSON-LD. As he says, we would loose interoperability if we did differently.

[riannella]

Hi @stuartmyles - any ideas how we update the current JSON section to JSON-LD ?

[riannella]

Dear all @stuartmyles @iherman @nevali @Jimflip @vroddon

@nitmws has said that we can create JSON-LD from the http://w3c.github.io/poe/vocab/ODRL22.ttl at http://rdf-translator.appspot.com/

It certainly produces some nice JSON-LD output.

The JSON-LD Context defined for the Annotation Vocab looks like this: http://w3c.github.io/web-annotation/vocab/wd/#json-ld-context

@iherman Do you know how they created this context? By hand??

[iherman]

@riannella : to be honest, I do not know. CC-ing this to @azaroth42 (https://github.com/azaroth42, a.k.a. Rob Sanderson).

(will also send a direct mail)

[azaroth42]

Yes, we created it by hand. The rationale being that the context is not just a simple translation of the schema, but instead an abstraction layer to turn an ontology into an API that's understandable and (more importantly) idiomatic for developers as opposed to ontologists. For example, oa:hasBody in the ontology (following the best practice of verb phase for predicate) is just body in the JSON-LD (following JSON conventions).

I'll try and take a look at the JSON work here (now that the Annotation specs are in PR).

[and hi @stuartmyles! :)]

[azaroth42]

Example context and the first example from ODRL2: http://tinyurl.com/jyude82

[riannella]

So, what then would be the manual process to create the (simplest) JSON-LD Context?

Do we just take all (200 or so) ODRL ontology terms (URIs) and list them like:

"Policy":           "o:Policy",
....
"policyUsage": "o:PolicyUsage"

And if the term is a property (and has a URI object) then we say:

"target":     {"@type": "@id", "@id": "o:target"},

Would that work?

[stuartmyles]

I've just noticed these emails with @stuartmyles mentions in them. Are these meant to be me alerting me somehow?!!?

Anyway, now that I've seen it I will trace back through the thread and see if I can contribute in any way. Apologies for not checking this email account sufficiently diligently before now.

Regards,

Stuart

On Thu, Jan 26, 2017 at 8:52 PM, Renato Iannella notifications@github.com wrote:

So, what then would be the manual process to create the (simplest) JSON-LD Context?

Do we just take all (200 or so) ODRL ontology terms (URIs) and list them like:

"Policy": "o:Policy", .... "policyUsage": "o:PolicyUsage"

And if the term is a property (and has a URI object) then we say:

"target": {"@type": "@id", "@id": "o:target"},

Would that work?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/46#issuecomment-275570050, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwBf-wE37A85Kn3IdQ9GzjSe2rmL35jks5rWU3WgaJpZM4KZWR0 .

[azaroth42]

@riannella That should work :) You would want to distinguish between @type:@id, and @type: @vocab if you want to avoid prefixes in the values. The distinction is described here: https://www.w3.org/TR/json-ld/#type-coercion

[stuartmyles]

I'm a bit confused as to where this (creating a JSON-LD mapping) stands now.

Based on Rob and Renato's emails, it sounds like someone needs to create a JSON-LD context file. And that, essentially, it needs to be done manually. Is that right? If so, is there someone already working on doing that? If not, then I can volunteer. (I just don't want to do it if someone - likely better qualified than me - is already slaving away).

I also looked at Rob's example earlier in this thread and it looks good to me. (In other words, it seems like it would be fine to ignore the JSON-LD context and just handle it like a proper JSON file, which is my definition of "good" in this situation!)

http://json-ld.org/playground/?startTab=tab-compacted&copyContext=true&json-ld=%7B%22%40context%22%3A%7B%22odrl%22%3A%22http%3A%2F%2Fwww.w3.org%2Fns%2Fodrl%2F2%2F%22%2C%22Set%22%3A%22odrl%3ASet%22%2C%22Permission%22%3A%22odrl%3APermission%22%2C%22Prohibition%22%3A%22odrl%3AProhibition%22%2C%22target%22%3A%22odrl%3Atarget%22%2C%22action%22%3A%7B%22%40id%22%3A%22odrl%3Aaction%22%2C%22%40type%22%3A%22%40vocab%22%7D%2C%22permission%22%3A%22odrl%3Apermission%22%2C%22prohibition%22%3A%22odrl%3Aprohibition%22%2C%22reproduce%22%3A%22odrl%3Areproduce%22%2C%22modify%22%3A%22odrl%3Amodify%22%2C%22id%22%3A%22%40id%22%2C%22type%22%3A%22%40type%22%7D%2C%22id%22%3A%22http%3A%2F%2Fexample.com%2Fpolicy%3A0099%22%2C%22type%22%3A%22Set%22%2C%22permission%22%3A%7B%22type%22%3A%22Permission%22%2C%22target%22%3A%22http%3A%2F%2Fexample.com%2Fasset%3A9898%22%2C%22action%22%3A%22reproduce%22%7D%2C%22prohibition%22%3A%7B%22type%22%3A%22Prohibition%22%2C%22target%22%3A%22http%3A%2F%2Fexample.com%2Fasset%3A9898%22%2C%22action%22%3A%22modify%22%7D%7D

On Fri, Jan 27, 2017 at 12:20 PM, Rob Sanderson notifications@github.com wrote:

@riannella https://github.com/riannella That should work :) You would want to distinguish between @type https://github.com/type:@id https://github.com/id, and @type https://github.com/type: @vocab https://github.com/vocab if you want to avoid prefixes in the values. The distinction is described here: https://www.w3.org/TR/json-ld/

type-coercion

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/46#issuecomment-275720914, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwBfyqBYIEvUyRvfWYeDUBqq2mAM3OPks5rWidLgaJpZM4KZWR0 .

[riannella]

@stuartmyles no one has started the manual creation of the JSON-LD context file. Please do 👍 . We need this asap to move the Vocab spec forward.

We also need to then update the narrative section on JSON-LD...I assume it will be shorter now?

[stuartmyles]

@azaroth42 looking at your example, it seems you rewrote the JSON - was that to make it easier to map it into JSON-LD? If so, I have some questions...

Here is the original JSON example:

{ "policytype": "http://www.w3.org/ns/odrl/2/Set", "policyid": "http://example.com/policy:0099", "permissions": [{ "target": "http://example.com/asset:9898", "action": "http://www.w3.org/ns/odrl/2/reproduce" }], "prohibitions": [{ "target": "http://example.com/asset:9898", "action": "http://www.w3.org/ns/odrl/2/modify" }] }

And here is your rewritten version (minus the context):

{ "id": "http://example.com/policy:0099", "type": "Set", "permission": { "type": "Permission", "action": "reproduce", "target": "http://example.com/asset:9898" }, "prohibition": { "type": "Prohibition", "action": "modify", "target": "http://example.com/asset:9898" } }

One obvious problem with the JSON-LD version: you can't have more than one permission or prohibition in a given expression! Is that a necessary restriction for the JSON-LD?

Also, I use full URLs for the actions (e.g. "action": "http://www.w3.org/ns/odrl/2/modify") whereas your example uses URLs that are built into the context (i.e. "action": "modify"). The use of full URLs is so that ODRL users can plug in whatever vocabulary of actions they want. Are we no longer able to use full URLs in JSON-LD?

[azaroth42]

You can specify that the property must be expressed as a singleton list, rather than reducing it to just an object. I simplified down, but that's not necessary for JSON-LD, just a choice I made at the time :)

And yes you can use full URLs. I think its a good practice for static URLs (such as using URLs as identifiers like 'modify') to reduce it to an entity in the context ... but that's certainly not necessary. The JSON in your example could, with a slightly modified context, be JSON-LD without change.

Similarly, id and type are good practice but also not necessary ... they could be policytype and policyid.

[riannella]

Just saw this job posting: https://www.upwork.com/job/Create-JSON-Context-Definition-for-ODRL_~0156ff5fdb318c478f/

Anyone have any idea who it could be from?

[riannella]

Should we map ODRL's policy uid and type to @id and @type in JSON-LD?

[simonstey]

Anyone have any idea who it could be from?

stuart as it seems :D (you can toggle open the feedback on the very bottom)

mapping of uid/type

yes

[riannella]

ok, cool, could be the first time anyone has made direct money from ODRL ;-)

@stuartmyles please ensure you use the latest turtle at: http://w3c.github.io/poe/vocab/ODRL22.ttl (not the ODRL21 version)

[stuartmyles]

Yes, this was from me. (It is good that you've seen it - I actually haven't gotten any responses, yet, so I wasn't certain whether it had worked! I've used this service a couple of times in the past and I normally get several responses over night. However, none so far, which is a bit ominous).

I looked at creating the ODRL Context myself. After some study, I decided that I could get to the level of being able to distinguish a good @context from a poor one, most likely. However, I don't think I can quickly become a sufficient expert in JSON-LD to be able to design a good context. I'm pretty confident in working with XML or JSON schema design, since I've worked in both areas for several years. But all I've really done for JSON-LD is read the primer and a few other associated documents.

I understand that we want to have the JSON-LD @context as part of the POE work, although I personally don't see that there's any business value in it. And, from what I can tell, it is unlikely that I myself will ever use JSON-LD in this or other contexts, so it doesn't seem really worthwhile me trying to become an expert in it. So, I thought I would try to find someone who might be able to provide that expertise. I've turned to upwork to try to find such a person.

As I said, I haven't received any bids, so it could be that this isn't going to work out. I also searched to see if I could find anyone with JSON-LD expertise. Plenty of people with JSON skills and even RDF. But no one even mentions JSON-LD (which reinforces my belief that there is no direct business value). However, if this is the way for us to pay off the "JSON-LD tax" and keep the overall POE effort moving forward, it would be worth it to me.

Regards,

Stuart

On Thu, Feb 2, 2017 at 7:14 PM, Renato Iannella notifications@github.com wrote:

Just saw this job posting: https://www.upwork.com/job/Create-JSON-Context-Definition-for-ODRL_~ 0156ff5fdb318c478f/

Anyone have any idea who it could be from?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/46#issuecomment-277126832, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwBfy25v1LprHC-bWQ0fu2nbhTPh5i_ks5rYnFNgaJpZM4KZWR0 .

[riannella]

I am slightly confused too...(being weened on XML...:-)

Doesn't the JSON-LD context also act as the JSON schema?

So in the Annotation json-ld context: http://w3c.github.io/web-annotation/vocab/wd/#json-ld-context

Then when a JSON person writes "Annotation", it really means "oa:Annotation" (and the latter keeps LD people happy)? ?

[iherman]

Doesn't the JSON-LD context also act as the JSON schema?

These two are completely different. JSON Schema is a separate semi-specification; "semi" in the sense that I am not sure it is really stable. Nor do I know how widespread it is. A JSON-LD context is very different. It does not "check" the JSON file (as a JSON Schema would do) but it rather maps the JSON content on something that RDF processors like.

So in the Annotation json-ld context: http://w3c.github.io/web-annotation/vocab/wd/#json-ld-context

Then when a JSON person writes "Annotation", it really means "oa:Annotation" (and the latter keeps LD people happy)? ?

Yes. A JSON-LD parser, when generating RDF, will expand "Annotation" into the URL.

[riannella]

So what do we do?

[iherman]

I am not sure I understand the question. Didn't we agree that we use JSON-LD as an encoding? If so, we must have a JSON-LD context file. What is the question?

[riannella]

Yes we did, but it seems that then does not address JSON developers (as well). I had hoped/assumed that we were going to support both - thru the "context".

[iherman]

You mean because it is not a JSON Schema, too?

I do not know how widespread is the usage of JSON Schema in the JSON developers' community. The fact that (afaik) it is still a moving target is not a good sign.

As far as I remember (@azaroth42 ?) we did look at JSON Schemas in the Annotation WG, and wondered whether it was worth defining a separate Schema file. But ended up not doing it.

In any case, it would indeed be a separate work item to do so.

[azaroth42]

JSON Schema is primarily a validation tool, in the same way that XML schemas are. We use it in the test suite for the Annotation WG to validate that documents conform to the specific JSON-LD serialization required, but did not make a single uber-schema as the complexity far outweighed any benefits.

JSON-LD's context document just maps from JSON to RDF, and does not make any requirements on structure or cardinality of properties or values. The two are mostly orthogonal, other than that they both need to refer to the names of keys in the JSON.

As far as use within the JSON developer community ... I haven't seen significant adoption, but it could be part of back end data management workflows.

[riannella]

@stuartmyles I've attempted to create the JSON-LD context file for ODRL. See: https://raw.githubusercontent.com/w3c/poe/gh-pages/vocab/ODRL22.jsonld

@azaroth42 I am not sure if you can have a look at this? I followed the template used by the annotation spec. I also tried to verify this in the JSON-LD playground but it gives me a processing error...and not sure where!

[stuartmyles]

Hi Renato,

How did you create the JSON-LD file? Was it automatically or by hand?

Right now, it won't work, since it doesn't match the JSON examples. Also, I notice some odd typos, e.g.

"function": {"@type": "@id", "@id": "odrl:fuction"},

Which is why I'm wondering how you did it.

However it is something and I can try to alter it to actually match the JSON schema.

I have gotten one person offering to help with the job posting. But they asked for three times what I was offering for the fee! And they said they would do the thing I said I did not want: to merely automatically generate the JSON-LD from the Ontology.

Regards,

Stuart

On Tue, Feb 7, 2017 at 10:53 PM, Renato Iannella notifications@github.com wrote:

@stuartmyles https://github.com/stuartmyles I've attempted to create the JSON-LD context file for ODRL. See: https://raw.githubusercontent.com/w3c/poe/gh-pages/vocab/ODRL22.jsonld

@azaroth42 https://github.com/azaroth42 I am not sure if you can have a look at this? I followed the template used by the annotation spec. I also tried to verify this in the JSON-LD playground but it gives me a processing error...and not sure where!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/46#issuecomment-278222211, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwBf0zFYZ19f9kW7ZK71BlFsKunjr0jks5raTw8gaJpZM4KZWR0 .

[riannella]

I wrote it by hand (2 hours of cut, copy, paste ;-)

I used the Annotation spec JSON-LD context as the template: http://w3c.github.io/web-annotation/vocab/wd/#json-ld-context

Basically, all classes, individuals, and properties (that are not taking URI objects) become: "xxx": "odrl:xxx"

Any property that takes a URI object becomes: "xxx": {"@type": "@id", "@id": "odrl:xxx"}

And where we are more specific, we can use the exact xsd:datatype in the first @id

That's the pattern I followed...I hope its correct...but I may have missed something fundamental ;-) (and, of course, I made some typos ;-)

I will email the JSON-LD editors direct (I know two of them) and ask them to verify/help us out...

(I think the freelancer option is not the best ;-)

[riannella]

Update: Gregg Kellogg (one of the JSON-LD editors) has agreed to help us out...

[gkellogg]

Well, one thing that makes the context invalid is on line 151, where meteredTime should be odrl:meteredTime; that seems to be the immediate source of the issue you found in the playground.

There are some other things you should consider:

As you discuss, properties who's range is a resource rather than a literal (similar to owl:objectProperty) should typically have @type: @id. However, then the resource comes from a constrained vocabulary, where the instances are defined in the context, you should use @type: @vocab.

This is due to the expansion rules, where @type: @id expands IRIs relative to the document base, and @type: @vocab relative to the vocabulary base, which also means they can be terms defined in the @context.

For example, the property leftOperand has a range of LeftOperand, which includes meteredTime as a member. So, I would make the term definition as follows:

{"@context": {
  ...
  "leftOperand":          {"@type": "@vocab", "@id": "odrl:leftOperand"},
  ...
}

This way, if you have something like {"leftOperand": "meteredValue"} it will expand as you expect.

Another thing to consider is if you want to make your context also be a vocabulary document. For example, we did this for CSVW, and Web Ontology took a similar tack. This way, you can feed both the OWL/RDFS vocabulary and the context at the same time, but it does come at the cost of having a larger document.

I typically use a script to generate all the vocabularies. For example, the CSVW script takes a CSV input and generates Turtle, JSON-LD and HTML+RDFa.

[riannella]

thanks @gkellogg for your review and suggestions!

[riannella]

I have updated the JSON-LD context file to use @vocab where appropriate. Also updated the JSON-LD section (very minimal).

[gkellogg]

Be careful with @vocab, if you think this will be combined with other contexts.

[riannella]

Thanks for the warning @gkellogg - can you give us an example of what could go wrong?

[gkellogg]

When combining contexts, the last one wins. I recommend the use of @vocab only when used by the final author of a JSON-LD document. If you explicitly define all terms in your vocabulary, you avoid this situation.

[stuartmyles]

Here's a draft JSON-LD context which appears to support all of the existing JSON encodings:

https://dl.dropboxusercontent.com/u/8555005/context.json

I want to do more testing, though, just to make sure.

Note that one difference in this ODRL Context (versus the one that Renato has been developing) is that it follows the convention we established for JSON - that explicit URIs always be used. This dramatically simplifies the @context, since it doesn't require the values of things like "leftoperand" to be included within the @context. This fits with the concept of different vocabularies (such as, say, RightsML) being able to be plugged into the JSON. If you don't follow that approach, then you would need a different @context file for a RightsML document versus an ODRL document, even if the only difference was some additional vocabulary items.

There are some changes in the JSON spec that need to be addressed. Mainly, these are bugs in the original spec.

Regards,

Stuart

On Fri, Feb 10, 2017 at 8:04 PM, Gregg Kellogg notifications@github.com wrote:

Well, one thing that makes the context invalid is on line 151, where meteredTime should be odrl:meteredTime; that seems to be the immediate source of the issue you found in the playground.

There are some other things you should consider:

As you discuss, properties who's range is a resource rather than a literal (similar to owl:objectProperty) should typically have @type: @id. However, then the resource comes from a constrained vocabulary, where the instances are defined in the context, you should use @type: @vocab.

This is due to the expansion rules, where @type: @id expands IRIs relative to the document base, and @type: @vocab relative to the vocabulary base, which also means they can be terms defined in the @context.

For example, the property leftOperand has a range of LeftOperand, which includes meteredTime as a member. So, I would make the term definition as follows:

{"@context": { ... "leftOperand": {"@type": "@vocab", "@id": "odrl:leftOperand"}, ... }

This way, if you have something like {"leftOperand": "meteredValue"} it will expand as you expect.

Another thing to consider is if you want to make your context also be a vocabulary document. For example, we did this for CSVW https://www.w3.org/ns/csvw, and Web Ontology https://www.w3.org/ns/oa took a similar tack. This way, you can feed both the OWL/RDFS vocabulary and the context at the same time, but it does come at the cost of having a larger document.

I typically use a script to generate all the vocabularies. For example, the CSVW script https://github.com/w3c/csvw/blob/gh-pages/ns/mk_vocab.rb takes a CSV input and generates Turtle, JSON-LD and HTML+RDFa.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/poe/issues/46#issuecomment-279107214, or mute the thread https://github.com/notifications/unsubscribe-auth/ADwBf2-q4JfjQTAa23eiDAJacFGfcwZxks5rbQkNgaJpZM4KZWR0 .

[riannella]

What is the impact then, if any, of not enumerating all the actions? (I ask since I see both the W3C Annotations and Activity Streams JSON-LD contexts do...)

[riannella]

There are some technical issues with the new context - namely "scope" is a property of a Party (or Asset) and we have an explicit "assignee_scope" - meaning every role would need to define that?