url is defined as @type: @id in the context document which precludes use of xsd:anyURI values

[trwnh]

w3c/activitypub#375 (comment)

The AS2-Vocab normative spec defines url as Link | xsd:anyUri

The AS2 context document defines url as @type: @id which disallows use of values (so no @type: @value)

Conclusions:

• Maybe define urlValue as a term with @type: xsd:anyURI
• Provide guidance for producers that url must always point to a Link node, and thus when referred to by @id alone after compaction, should respond with a Link node if content negotiation is used

[nightpool]

that seems overly pedantic. Has this caused a problem for any implementor ever? Or is this just a "spec cleanliness" problem? Priority of Constituencies says that we shouldn't make the implementation for consumers super complicated just to fix some obscure linked data theory issue that nobody notices in practice

…

On Mon, Apr 29, 2024, 8:48 AM a ***@***.***> wrote: w3c/activitypub#375 (comment) <w3c/activitypub#375 (comment)> The AS2-Vocab normative spec defines url as Link | xsd:anyUri The AS2 context document defines url as @type: @id which disallows use of values (so no @type: @value) Conclusions: - Maybe define urlValue as a term with @type: xsd:anyUri - Provide guidance for producers that url must always point to a Link node, and thus when referred to by @id alone after compaction, should respond with a Link node if content negotiation is used — Reply to this email directly, view it on GitHub <#596>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCVYBARY5CV4DHGBP7VTY7ZFR7AVCNFSM6AAAAABG6L5JSWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3DSMJQGMYTGOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[trwnh]

@nightpool this actually simplifies things for consumers, in that they no longer have to deal with the question of "wait, is this just a uri or can i fetch it and get more info about the Link?” if producers are doing the right thing, the answer should always be "yes, you can fetch more info, it is always a Link". consumers now only have to deal with handling the "embedded or not" issue. i'd actually go further and say that producers should consider making Links always be embedded

[steve-bate]

Has this caused a problem for any implementor ever?

This does cause problems in some contexts, especially for linked-data consumers, but even for JSON-only consumers (long discussion in #498, which you participated in back in 2018).

Like @trwnh said, when a developer sees a non-embedded url property, there's no way to know if it's a Link reference or something else (an image, HTML page, etc.) without dereferencing it and determining the content type.

(Warning: potentially obscure linked data discussion follows...)

The Link | xsd:anyUri range is ambiguous and contradictory. It can't be represented in the OWL ontology, for example, since it declares the property to be both an object property and a data property (union of the types).

It's difficult to make sense of it, but the Link subset refers to either a Link URI (which looks like an xsd:anyUri value) or a blank node identifier (an embedded object with no identifier in the JSON-LD serialization). The xsd:anyUri range subset refers to a data value with a URI syntax. In JSON-LD, "any URI" will have the same form as a Link URI so there's an ambiguity.

[evanp]

So we have a problem here, in that the text is canonical, but the specification is not realisable in JSON-LD. Unfortunately, we do have examples in the text using both Link and bare URLs. It's pretty clear that the intention is to use both, not just Link.

We think that a bare URL will work here, but the implication is that it is the URL for a Link object, which is rarely the case. The primer page on URLs as values gives some guidance, but it would be great to have a clearer path here. Definitely something to consider in the next version.

[evanp]

One thing that's important to recognize is that @trwnh is recommending that even when an URL looks like an URL for a binary representation, like an image, it should still return Activity Streams 2.0 Link object when fetched with Accept: application/activity+json (or other JSON types).

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Link",
    "id": "https://example.com/uploads/file123.png",
    "href": "https://example.com/uploads/file123.png",
    "mediaType": "image/png",
    "name": "The numbers 1, 2, and 3"
}

I think this is a nice solution and would be good to add to the Primer page.