owl file vs jsonld context

[sandhawke]

Please Indicate One:

• Editorial
• Question
• Feedback
• Blocking Issue
• Non-Blocking Issue

Please Describe the Issue:

In the drafts, Core linked to ./activitystreams2-context.jsonld and Vocabulary linked to ./activitystreams2.owl

It seems to me both of those documents need to share https://www.w3.org/ns/activitystreams, if we're going to follow Linked Data principles.

1. Anyone want to convert https://github.com/w3c/activitystreams/blob/master/vocabulary/activitystreams2.owl to JSON-LD and syntactically merge it into the context file? I'm not sure where the master of the context lives right now.

2. Will that cause any problems? The context file will be bigger. I suppose we could use owl:import, although that might not work with as many tools.

[akuckartz]

👍

[sandhawke]

@akuckartz thoughts on owl:import? Do you know a tool that would convert the ontology to reasonable json-ld?

[gobengo]

https://www.bountysource.com/issues/44080098-owl-file-vs-jsonld-context

[acka47]

I was confused by only getting the JSON-LD context when looking up https://www.w3.org/ns/activitystreams ($ curl -LH "accept:application/ld+json" https://www.w3.org/ns/activitystreams) as I expected an RDFS or OWL file. When I did not get RDFS/OWL I concluded that no such representation of the vocab exists.

Then I read in the AS Vocabulary definition:

A non-normative turtle definition of the Activity Streams 2.0 vocabulary is provided here and/or at the namespace

Great to see that the RDFS/OWL version exists but unfortunately the spec incorrectly says that you can fetch it from the namespace.

How to best publish a vocabulary alongside its context is a general question. With regard to a answer, one could also do this:

1. Provide the OWL file via the namespace
2. Link to the context via a link header

2.) is also done by schema.org:

$ curl -I https://schema.org
HTTP/2 200 
access-control-allow-credentials: true
access-control-allow-headers: Accept
access-control-allow-methods: GET
access-control-allow-origin: *
access-control-expose-headers: Link
link: </docs/jsonldcontext.jsonld>; rel="alternate"; type="application/ld+json
...

However, ths approach probably has some drawbacks and will probably break applications that get the context directly from https://www.w3.org/ns/activitystreams.

The approach outlined in this issue seems to be the better option. If I understand it correctly, you want to publish under the namespace not only the JSON-LD context but in addition the whole RDFS/OWL vocabulary as JSON-LD. I quickly put one version of this together with the help of https://rdf-translator.appspot.com & https://json-ld.org/playground/: https://gist.github.com/acka47/f78b0a7803e0c5ffdac171551f6fe638

Is this the thing you imagine (probably without the bnode IDs and some nested objects instead)?

[pukkamustard]

Is this the thing you imagine (probably without the bnode IDs and some nested objects instead)?

That's great!

Another approach by other W3C namespaces is to use HTTP content-type negotiation to either return the JSON-LD context or the OWL file. For exampl:

curl -LH "accept:application/ld+json" https://www.w3.org/ns/ldp

Returns a JSON-LD context. Whereas

curl -LH "accept:text/turtle" https://www.w3.org/ns/ldp

Returns the full vocabulary as Turtle.

It would be very nice to have this working as well for ActivityStreams. This would allow using the Vocabulary without doing significant amount of JSON-LD processing.

Slightly off-topic (should probably be a new issue):

Great to see that the RDFS/OWL version exists but unfortunately the spec incorrectly says that you can fetch it from the namespace.

Unfortunately this is outdated. Somethings I think are outdated or missing:

• the inbox property is missing (and some others)
• uses http instead of https as base uri

[acka47]

the inbox property is missing (and some others)

The inbox property is taken from the Linked Data Platform vocabulary: https://www.w3.org/ns/ldp#inbox (see also $ curl -H "accept:application/ld+json" https://www.w3.org/ns/activitystreams | grep -A 2 inbox)

uses http instead of https as base uri

I think there already was some discussion about this but I can not find it.

[evanp]

I will work on ensuring that the JSON-LD context is the master document, and will automatically generate the OWL document if possible. I'll need to check with W3C contacts to see if we can set up the content negotiation.

[csarven]

the inbox property is missing (and some others)
uses http instead of https as base uri

The vocab URIs in the LDP ns uses the http: URI scheme. The current AS JSON-LD context is correct.

---

What Sandro was suggesting is that the vocab and the JSON-LD context are available from the same URI ( https://www.w3.org/ns/activitystreams ). This is practical and AFAIK, https://www.w3.org/ns/activitystreams is the base URI for terms that's used by RDF publishers and consumers.

However, I may be wrong but if the same URI is used for the vocab and the JSON-LD context, it may be a URI collision (see #504 (comment) )

Generating a Turtle towards the vocab from the JSON-LD context will not result in anything since the JSON-LD context does not currently include any definitions.

So, I'm a bit puzzled about what's the best course of action, and was hoping for guidance from W3C and everyone. It'd be great for me to be wrong about the collision.. and that the definitions can be rolled into the representation available from https://www.w3.org/ns/activitystreams and have conneg for application/ld+json, and text/turtle.

[melvincarvalho]

So, I'm a bit puzzled

I'm a little perplexed, however. Isn't it true that all ActivityStreams objects reference a vocabulary via the @context, and that currently, this vocabulary is absent?

have conneg for application/ld+json, and text/turtle

Regarding the implementation of content negotiation for application/ld+json and text/turtle, I have some reservations. We've seen numerous challenges over the years in implementing content negotiation correctly, including within Solid. Do you think it's feasible to execute this without issues within a reasonable timeframe?

[csarven]

I'm not aware of implementations having issues with conneg in Solid. If you can follow-up on that with links in the Solid CG, that'd be helpful.

AFAIK, the W3C server has been correctly responding to ns/ conneg requests for a long time now, e.g.:

$ curl -iLH'Accept: text/turtle' http://www.w3.org/ns/oa
$ curl -iLH'Accept: application/ld+json' http://www.w3.org/ns/oa

And in the case when the server can't provide a requested representation, it responds properly with 406, and suggest available variants, e.g.,:

$ curl -iLH'Accept: text/foobarbazqux' http://www.w3.org/ns/oa

HTTP/2 406
content-type: text/html; charset=iso-8859-1
...
<ul>
<li><a href="oa.html">oa.html</a> , type text/html</li>
<li><a href="oa.rdf">oa.rdf</a> , type application/rdf+xml</li>
<li><a href="oa.ttl">oa.ttl</a> , type text/turtle</li>
<li><a href="oa.jsonld">oa.jsonld</a> , type application/ld+json</li>
<li><a href="oa.json">oa.json</a> , type application/json</li>
</ul>

So, yes, W3C can set up conneg and it is not an issue.

As I see it, the core concern boils down to whether it is correct or meaningful to have a resource in which the JSON-LD representation includes the JSON-LD context and the vocab (information in OWL and/or RDFS).

If the above is okay, what Evan is trying to makes sense to me. AFAICT, W3C Team contact for SWICG is @pchampin -- (not) sorry to summon you =)

A JSON-LD document can be the source document including the JSON-LD context and the vocab (which includes the human-readable labels), where the other formats like Turtle and possibly HTML can be generated. If the vocab is not part of the source JSON-LD document, there is no point in generating Turtle. (Aside: RDF/XML is not needed.)

See also the HTML representation of ns/activitystreams which includes content about the JSON-LD context and the vocab (but it actually links to the spec):

$ curl -LH'Accept: text/html' https://www.w3.org/ns/activitystreams

But again, conneg is fine:

$ curl -LH'Accept: application/ld+json' https://www.w3.org/ns/activitystreams

It is the content of the representations that needs to be sort out, and whether there are URI collisions or not.

[melvincarvalho]

I'm not aware of implementations having issues with conneg ...

Surely all mime types should give back the same data (ie triples) in conneg, including HTML?

[csarven]

I hope you don't mind but I prefer to continue this conneg discussion elsewhere. I'll respond briefly and leave it at that from my end.

As per RFC 7231 (or RFC 9110), "sameness" (equivalent representations) is determined by the algorithm selecting the response, and surely the URI owner as part of social convention ensures the semantics of the resource is preserved (as intended) across representations over time. So, it does not strictly entail that "same" data/triples is literally required to be part of all representations. It is not always possible any way. As per RDF11-CONCEPT (with concrete RDF syntaxes), implementations can (and do) practically provide the same data within the framework of HTTP. There are social conventions, so we wouldn't normally expect or consider it correct for PNG and HTML representations to be the "same", although some may argue that. We'd expect PNG and JPEG to be equivalent. Similarly, the RDF graph in JSON-LD and Turtle may not be isomorphic, and that's okay. Same goes for Turtle and HTML with or without embedded RDF. All of those combinations for example can be considered to be equivalent representations.

[melvincarvalho]

Similarly, the RDF graph in JSON-LD and Turtle may not be isomorphic, and that's okay

If JSON-LD and Turtle are giving back different triples you have a BIG problem. Because the client wont know which of the serializations to take. Different serializations will give different results, inconsistent UX, security issues, wide attack surface etc.