Update ns URIs in Turtle

[csarven]

No description provided.

[sandhawke]

I'm confused. Why would you do this?

As in reading it, this patch would change the namespace URI, breaking everything that uses this file, and making it incompatible with standard AS.

And it's not really motivated, since w3.org uses hsts, so network traffic will use TLS even for http URLs.

[csarven]

This document wasn't updated to reflect the changes regarding the AS2 ns which is 1) https 2) canonical at https://www.w3.org/ns/activitystreams .

The stand alone publishling of this Turtle at http(s)://www.w3.org/ns/activitystreams-owl in fact causes the confusion - that URI can/should probably be removed.

Ultimately https://www.w3.org/ns/activitystreams is what matters and that simply needs to have conneg available for Turtle ie. this OWL/Turtle doc.

[gobengo]

@sandhawke The TR does say implementations SHOULD use https, and MAY use http.

From https://www.w3.org/TR/activitystreams-core/#jsonld

Implementations producing Activity Streams 2.0 documents should include a @context property with a value that includes a reference to the normative Activity Streams 2.0 JSON-LD @context definition using the URL " https://www.w3.org/ns/activitystreams"

I think at some earlier point before TR, the most preferable @context value was only with http, but that seems to have changed.

Given this (which you may not have been aware of?), I don't see what you mean by this PR making the relevant file "incompatible with standard AS.". It seems it would make it more compatible with the TR.

[gobengo]

@csarven To help a bit with any concerns about exising clients depending on this file as it already is (with http), do you think it would be reasonable to add an owl:sameAs http://www.w3.org/ns/activitystreams?

(Some kind of info that this resource at https://www.w3.org/ns/activitystreams is the same as the previously described one called http://www.w3.org/ns/activitystreams)

[csarven]

https was the intended for REC/context/ns and what have you. http only exists in previous states "unofficially".

The Turtle doc wasn't part of the deliverable, so it doesn't necessarily need to exist as far as the WG was concerned. It is a nice to have and is useful if made available from the AS2 HTTPS ns.

I don't think we need to bother with sameAs because the http URIs in activitystreams-owl is both incorrect (outdated) and unofficial. Although I ack the appeal, I'm not sure if we need to be concerned about "existing clients" using http.

Keep it as simple as it can be:

• Update the URIs in Turtle (this PR).
• Have that Turtle available from https://www.w3.org/ns/activitystreams

Edit: After above, decommissioning http(s)://www.w3.org/ns/activitystreams-owl would eliminate future confusion as well.

[sandhawke]

@gobengo I think you're confusing the context with the namespace. In practice they are often the same string, but that's not necessary. Bizarrely, I don't see an evidence in the REC of what the namespace is supposed to be. But I do see the current context document does use https for the namespace, so, yes, this change to the turtle document makes sense, and I was mistaken above. I was forgetting that we changed the namespace to add the "s" against my strong advice and in confusing contradiction to all the other w3.org namespaces, for IMHO insufficient reason. Grumble grumble. But I guess we did. And I remember I've been tripped up by this several times before.

So, I've no problem with this change per se.

I'm not entirely sure editing a document of unknown status sends the right message, though. If we're going to touch it, should we also add a big comment saying this document might not be aligned with AS2? Or are people motivated to make sure it is aligned?

In the twitter discussion I was thinking the Turtle document would just be a Turtle serialization of the triples in the JSON-LD document, but I now see the JSON-LD document has no triples - it's just a context, not an ontology. That means we have no approved ontology, as far as I can tell. It looks like this Turtle document was proposed at some point but never approved. Happy to be proven wrong.

[csarven]

proposed at some point but never approved

Never approved for what? To serve some purpose other than having it published at ns/activitystreams-owl ? It was "approved" enough to have W3C publish it while its essential URIs refer to the http AS2 ns. It was "approved" enough to have it sit there without getting fixed.

If all this stuff was wrapped up during the WG, we wouldn't be discussing this or getting fixes in now and then when we spot them... but there is no point in having that discussion now. Or throwing "strong advice" years later.

IMO, what matters now is cleaning up what was not done or at least minimising confusion. I don't particularly care how that's reasoned or even which URIs are used. Some people are coming across activitystreams-owl somehow and wondering what's going on. I'm only voicing/proposing this to find a painless way forward. If activitstreams-owl is not "approved", remove it. Eliminate confusion. If "approved", get it fixed and publish it from a sensible place ( IMO: https://www.w3.org/ns/activitystreams ) .. again to eliminate confusion and to put something out there in a way that wouldn't come as a surprise. Leaving it as is is no good.

I'll leave it up to you (as authority) to decide on the correct way to name and publish stuff under w3.org based on your experience. After all, it is not under my jurisdiction.

[sandhawke]

It sounds like perhaps we're both in the position of not caring about AS2, or being paid or otherwise motivated to maintain it, but also we don't want to see people misled/harmed by outdated documents, error, or whatever.

My understanding is this stuff is now owned by the CG. If there's any disagreement, it's up to the CG to come to a consensus resolution. I've added @cwebber (CG chair) as another collaborator on this repo so he can implement any decision on github. I (or webreq@w3.org) can implement any decision on w3.org, if it comes to that.

My position/advice is that we shouldn't put it on w3.org until/unless at least one person, preferably two, have carefully vetted the document, and hopefully used it in some real AS2 software. Otherwise it's likely to mislead people even more than you report it currently doing, by being subtly wrong. I'm not likely to block consensus defending that position.

If no one finds that vetting/implementation a good use of their time, then either adding a big warning or deleting it seems good to me. My preference would be a warning, explaining the document hasn't been maintained to match changes in AS2 and hasn't been tested.

Maybe whoever you spoke to who was misled wants to weigh in about what would have been most helpful to them?

[csarven]

Sandro, my interest is in clarifying and helping to wrap up what was left unfinished by W3C (Team). It goes without saying that I do care about AS2 since I've been raising issues. The exact technical solutions is beside the point and I may be or have been completely wrong on the suggestions. If you are making decisions on behalf of W3C (Team), then the minimal expectation here is that you show the way forward. Stating that you had strong advice contrary to what was proposed (mainly by me!) is not particularly useful, especially when you, as W3C (Team) have decided to follow through and bypassed the W3C Social CG. Pardon me but you certainly can not have it both ways.

If W3C Social CG is responsible to approve changes pertaining to either one or more of: ns, context, vocab and whatever else, then I suppose all changes made after the W3C Social WG and while under Social CG's jurisdiction should probably be re-reviewed.

[tpluscode]

I just opened #515 today without realising there was this PR.

Could we possibly proceed somehow here?

[csarven]

A summary for anyone running into this and related issues in the future:

---

There are a number of issues and we sort of ended up with the worst deal. URI collision.

w3.org upgrades http request to https whether client signals for it (redirects) or not.

The JSON-LD context URL should've been https://www.w3.org/ns/activitystreams.jsonld (or maybe even http://www.w3.org/ns/activitystreams.jsonld).

The as namespace URI should've been http://www.w3.org/ns/activitystreams#.

Right. The ship has sailed.

We ended up using https://www.w3.org/ns/activitystreams as the JSON-LD context URL and it has the as term mapped to https://www.w3.org/ns/activitystreams#

The RDF ontology document can be found in http(s)://www.w3.org/ns/activitystreams-owl (or referenced URI of Content-Location) - this PR updates the source of that. The as prefix uses http://www.w3.org/ns/activitystreams#.

Everything else remaining the same, it doesn't really matter whether this PR is merged or not.. because both http and https resolves to the context URL. Well, sort of. application/ld+json will gives the JSON-LD context document, text/html gives an HTML document about the namespace.

It may be safer to close this PR without merging.

---

I don't expect the JSON-LD context URL to change or even the as term within mapping to an http URI (instead of https) at this point. If either the context URL is suffixed with .jsonld or the as mapping uses http, then the RDF ontology can work out and be Linked Data friendly..

In the meantime, the RDF ontology (definitions) can be brought up to speed to help systems that rely on the definitions.

Perhaps there is a way to improve the situation..

[phtyson]

In the meantime, the RDF ontology (definitions) can be brought up to speed to help systems that rely on the definitions.

What is preventing this from happening?

Improving accessibility of the ontology (#606) won't do much good if the namespace URI is wrong. Others will to continue to trip up (as I did) because activitystreams.jsonld says "as": "https://www.w3.org/ns/activitystreams#" and activitystreams2.owl says @prefix as: <http://www.w3.org/ns/activitystreams#> .

[csarven]

Following up on #416 (comment) , the minimal change that may satisfactory is as follows. This is based on the fundamental consideration that the URI https://www.w3.org/ns/activitystreams is in use by both JSON-LD context and RDF content producers/consumers.

PROPOSAL:

Incorporate the contents of activitystreams2.owl into the JSON-LD context, including human-readable labels and schema information.

https://www.w3.org/ns/activitystreams can continue to serve the JSON-LD context when requested with application/ld+json in addition to now providing the vocabulary.

If this proposal (or a similar one) is adopted and implemented, this PR can be closed and activitystreams2.owl can be deleted.

Once again, I urge the W3C Team to review this (or other) proposals and take action, as they are the URI owners (irrespective to what participants unaffiliated with W3C prefers/wants) as part of their service to the web at large. Thanks!

[pchampin]

+1 to this PR, as the current state (using http:// IRIs for the terms of the ActivityStreams vocabulary) is inconsistent with the Recommendation (defining them as https:// IRIs).

this PR can be closed and activitystreams2.owl can be deleted.

I'm reluctant to remove it, as people may have come to depend on it (?). However, I'm also +1 on including the vocabulary description in https://www.w3.org/ns/activitystreams, as I commented elsewhere.