AS2 Ontology: make OWL prefix consistent with JSON-LD context

[steve-bate]

Duplicate of #504 ; I suggest closing this PR. Please see discussion.

AFAICT, this is not a duplicate. I had read that discussion before and I've re-read it to refresh my memory. That discussion appears to be focused on network retrieval of JSON-LD contexts (and OWL ontologies?), protocol upgrades (HTTP -> HTTPS), and content negotiation. This PR addresses none of that.

When JSON-LD is expanded using the normative AS2 context, it will expand AS2 terms with the prefix defined for the "as" term. If this prefix does not match the prefix defined in the ontology, then the URIs in the ontology will not match the expanded JSON-LD (after it is converted to RDF triples). This is independent of HTTP vs HTTPS or network retrieval in general. For both the JSON-LD context and the OWL ontology, the network URL for the document is orthogonal to the URI prefixes defined for JSON-LD and OWL. The prefixes are defined in the document content, independent of where the document was loaded -- network retrieval, local file cache, database, etc.).

In this case, the prefixes are not consistent between JSON-LD and OWL. Since the JSON-LD is normative and the OWL is not, it seems reasonable to change the OWL prefix to be consistent with the JSON-LD prefix. Again, although the change is from "http" to "https", this is not a network protocol issue. The prefixes could be urn:example:foo# and urn:example:bar# with the same effect.

[csarven]

I think this is rather splitting hairs but I'm not sure to what end.

https://github.com/w3c/activitystreams/pull/504/files#diff-a3efa9bb1fdf04e14cae017f572eb5151b20ba313fba85a79e76b102231f8bfbR2 literally includes the change that's also proposed in this PR.

What you're saying is that your change is not with that intention / perspective, which is fine, because there can of course be multiple reasons to make the same change. Bottom line: alters the namespace in the document. I am however raising a major caution about such change and that some input / reviews would be really useful.

The typical use of the RDF/OWL document and dare I say the LD practise is that the IRI/URI/URLs resolve. That's so that all the URIs in that document can be referenced and processed and navigated from by RDF processors (or anything else for that matter). The purpose of that particular Turtle serialization (RDF/OWL document) is not merely about matching the JSON-LD context irrespective to what documents were "normative" and what not. If anything, the RDF/OWL document first and foremost match Activity Vocabulary, if we want to play the "normative" specification card.

[steve-bate]

Bottom line: alters the namespace in the document. I am however raising a major caution about such change and that some input / reviews would be really useful.

Yes, alters it, as in, corrects it.

The typical use of the RDF/OWL document and dare I say the LD practise is that the IRI/URI/URLs resolve. That's so that all the URIs in that document can be referenced and processed and navigated from by RDF processors (or anything else for that matter).

The Turtle parsers I've used do not try to resolve prefixes from network locations. Neither does JSON-LD. If I embed prefix definitions (versus referencing an external context document), the libraries will not try to resolve the embedded prefixes. AFAIK, there's no requirement that the prefixes defined in an external JSON-LD context document match the network location of the document. For example, a context might define many prefixes in a single document. Those prefixes may or may not be network-retrievable (such as URNs).

The "@context": "https://www.w3.org/ns/activitystreams" entry in an AS2 document is not a prefix. It's a URL of an external context document that happens to look like the as prefix definition contained in that document. I could serve it from https://stevebate.net/ns/as2.jsonld, for example, and it would work just as well.

The purpose of that particular Turtle serialization (RDF/OWL document) is not merely about matching the JSON-LD context irrespective to what documents were "normative" and what not.

Not merely or exclusively, but I believe making the two documents consistent is a basic prerequisite for the AS2 OWL ontology to be widely useful. The normative status of the two documents is relevant to deciding on the most effective way to make the documents consistent given the significant overhead of changing normative documents compared to non-normative ones. Other than that, I have no personal preference for whether the URI prefixes start with the letters "http" or "https" (or anything else), just that they match.

If anything, the RDF/OWL document first and foremost match Activity Vocabulary, if we want to play the "normative" specification card.

Do you mean what's defined in https://www.w3.org/TR/activitystreams-vocabulary/#types ?

Base URI: https://www.w3.org/ns/activitystreams#.

If so, that's consistent with this PR.

[csarven]

Yes, alters it, as in, corrects it.

As mentioned, that's already covered by PR 504 because it takes several things into account, not only the alignment for JSON-LD context!

The RDF/OWL document is not strictly depending on the JSON-LD context at all, or any particular "normative" document. The ns lives outside of such documents.

Which is why it is important to have a broader view on what such change entails. See also https://github.com/w3c/activitystreams/issues/416 which goes together with 504.

The Turtle parsers I've used do not try to resolve prefixes from network locations.

Of course by definition the Turtle parser is not required to resolve the prefixes.

But the point being that the information in the Turtle document is not something that's limited or isolated to a database/software managing ontologies/graphs. So, yes, there is a strong expectation (not necessarily a "requirement") that the HTTP URIs in the Turtle document will resolve.

Do you mean what's defined in https://www.w3.org/TR/activitystreams-vocabulary/#types ?

No, the whole vocabulary in: https://www.w3.org/TR/activitystreams-vocabulary/ - after all, we're quite literally copying the definitions from there into the RDF document.

I'd contend that at present the following documents has more significance to the OWL / Turtle document than the JSON-LD context, because they include definitions that's pertinent and useful under the AS2 ns:

• Activity Vocabulary
• ActivityStreams 2.0 Terms (i.e., the HTML serialization)
• ActivityPub
• DID Core

[steve-bate]

As mentioned, that's already covered by PR 504 because it takes several things into account, not only the alignment for JSON-LD context!

I agree. It conflates/confuses several orthogonal issues.

The RDF/OWL document is not strictly depending on the JSON-LD context at all, or any particular "normative" document. The ns lives outside of such documents.

I agree. It is not "strictly" dependent. However, the ontology is much less useful if the associated URIs are inconsistent with the RDF generated from expanding the AS2 JSON-LD documents.

Which is why it is important to have a broader view on what such change entails. See also #416 which goes together with 504.

416 makes very little sense (other than suggesting the URI prefixes be made consistent). AFAIK, there's no way, in general, to merge an OWL ontology into a JSON-LD context document, which is what the issue suggests. Note this is different than representing the OWL ontology as JSON-LD content. That's clearly possible since JSON-LD is an RDF serialization.

But the point being that the information in the Turtle document is not something that's limited or isolated to a database/software managing ontologies/graphs. So, yes, there is a strong expectation (not necessarily a "requirement") that the HTTP URIs in the Turtle document will resolve.

Here's another strong expectation. Given an AP/AS2 JSON-LD document, it can be expanded and converted to an RDF graph that can be effectively merged with another RDF graph containing the AS2 OWL ontology (where "effective" means the URIs, such as class and property URIs, are consistent). The current AS2 OWL prefix definition does not support that and, for that purpose, it is broken.

Do you mean what's defined in https://www.w3.org/TR/activitystreams-vocabulary/#types ?

No, the whole vocabulary in: https://www.w3.org/TR/activitystreams-vocabulary/ - after all, we're quite literally copying the definitions from there into the RDF document.

If that were literally true, this PR and several others (some that have been open for many years) would not be needed -- and the AS2 ontology prefix would be correct.

In any case, thanks for taking the time to clarify your thoughts on the topic. I'll move along now since I don't plan to use the current ontology until there's active maintenance of it and it's consistent with the normative AP/AS2 recommendations. You seem to have other uses in mind that don't require that consistency. I sincerely wish you good luck with whatever that is.