activitystreams
activitystreams copied to clipboard
w3c
Please mention the fragment identifier requirements for ActivityStreams media type
Please Indicate One:
- [x] Editorial
- [ ] Question
- [ ] Feedback
- [ ] Blocking Issue
- [ ] Non-Blocking Issue
Please Describe the Issue:
JSON-LD specifies the fragment identifier, ActivityStreams does not. if the media types are intended to be synonymous, then they should probably follow the same fragment identifier rules.
not doing so would lead to all sorts of interoperability issues.
I don't think that JSON-LD actually has a mechanism for resolving parts of a JSON-LD document using fragment identifiers. We give some tips here: https://www.w3.org/wiki/ActivityPub/Primer/Object_identifiers#Fragments but it's not well-defined.
The JSON-LD spec does have a definition for referring to JSON-LD embedded with a
https://www.w3.org/TR/json-ld11/#locating-a-specific-json-ld-script-element
I don't think it's easy for ActivityPub processors (clients or servers) to reference AS2 this way, but I could see using it for embedding AS2 objects into a Web app that the local JavaScript could use. However, in this case, using the same application/ld+json type would probably be fine.
you can see it defined under IANA considerations - JSON-LD 1.1, where it says:
Fragment identifiers used with application/ld+json are treated as in RDF syntaxes, as per RDF 1.1 Concepts and Abstract Syntax [RDF11-CONCEPTS].
also related: https://github.com/w3c/activitypub/issues/367
Lots of good ideas there, but no single obvious consensus answer, and I suspect there won't be one any time soon. It's great that JSON-LD specifies fragment handling! But that's not an answer for AP or AS2, since afaik neither of those requires (or is, strictly speaking) JSON-LD.
From the primer page:
Publishers should avoid using fragments in object identifiers for ActivityPub, because there is not a standard defined for dereferencing them.
(Obviously other fragment standards exist, as you all are discussing, so I expect the wording here means "AP itself doesn't have a standard defined.")
unfortunately, if you're using application/ld+json; profile="https://www.w3.org/ns/activitystreams" (instead of application/activity+json), then you're using JSON-LD. thus, if they're supposed to be synonymous... it would be unfortunate to handle them differently.
Maybe! That's a big if, since much of the fediverse is on application/activity+json. AS2 clearly isn't JSON-LD, and AP is also clear that it can be JSON-LD compatible, but doesn't have to be. (@evanp correct me if I'm wrong!)
Mime types are useful! But it seems like a bit of a stretch to say that they'd mandate that much expectation (requirement) of behavior here.
it might be useful to raise this issue on art@ietf or thereabouts, then. they probably know more about this stuff than we do.
Whether "much" of the "fediverse" is "on" (or off) JSON-LD is not relevant to this issue. AFAICT, "much" of the AP-verse is using fragment identifiers in application/activity+json representations.
As there is publicly verifiable deployment out there, the editorial (or other) feedback requested in this issue is I think fairly valid.
Moreover, "much" of the AP-verse appears to use JSON-LD and finds it compatible (as per AP and AS Core). Anecdotal evidence from a server using the Mastodon implementation FWIW :
$ curl -iLH'Accept: application/ld+json' https://w3c.social/users/csarven
HTTP/2 200
server: nginx/1.18.0
date: Fri, 09 Aug 2024 17:48:19 GMT
content-type: application/activity+json; charset=utf-8
...
{"@context":["https://www.w3.org/ns/activitystreams"...
Successful response including JSON-LD context. Equivalent representation (content-type, content-length, etag..) with identical JSON-LD content at:
$ curl -iLH'Accept: application/activity+json' https://w3c.social/users/csarven
I guess we have two options here. Since application/activity+json is a synonym for ld+json, we can defer to the jsonld spec implicitly. however, it seems like a fair expectation to define this fragment syntax explicitly.
Specifically, we should add a section on Fragment Identifier Requirements. i think we have a choice between following jsonld requirements, eg no meaning except identity, or adding a way to look up a property of the resource.
Sounds like this issue is evolving into more or less the same question as https://github.com/w3c/activitypub/issues/367 ? I'm happy to merge them if so.
...oh, they're re the two different specs. OK. Even so, might be worth addressing them together, and then afterward deciding which language to add to which spec, or errata, or primers, etc.
AP servers and clients conform to RFC 7231 and RFC 3986/3987, so by definition, they can work with fragment identifiers when necessary.
Any software generating or consuming content using AS2 is expected to understand "anyURI" (which optionally includes fragment identifiers).
AP and AS2 already have strong compatibility with JSON-LD, so I believe deferring to JSON-LD for fragment identifiers will maintain that alignment without introducing any additional constraints or definitions.
Aside:
AS2 also doesn't constrain the URI scheme for the id property.
Servers have always had the right, and can still impose their own constraints on a request target by rejecting the request with a 422 status code when they consider any part of the content to be semantically erroneous.