`href` has inconsistent typing in the term definition (AS2-Vocab vs jsonld context)

[trwnh]

w3c/activitypub#375 (comment)

In the AS2-Vocab normative recommendation, href is defined to always be xsd:anyURI

In the AS2 context document, it is not defined as such

Conclusion: Make the context document consistent with the normative spec

EDIT: see #595 (comment) for further discussion -- the context document should not be changed, as it is actually correct. Rather, AS2-Vocab should probably clarify the range to be "Reference".

[evanp]

This seems like a good idea to make a direct change to the context document.

The Activity Vocabulary clearly gives the type for href. The context document has a similar but not identical type. The hole that that opens, namely including an Object or Link as the href value, is so clearly outside the intention of the property that it should not be a problem to close up this hole.

I'd recommend making a change to the context document to reflect the text correctly.

[dahlia]

This same issue affects other properties as well. For example, icon and image have similar inconsistencies:

• ActivityStreams Vocabulary: Both have range Image | Link
• JSON-LD Context: Both are defined with @type: "@id"
• Real-world usage: Often used with bare URL strings (e.g., "icon": "https://example.com/avatar.png")

The W3C primer acknowledges this:

assume that a bare string is the href of a Link object, not an id

But JSON-LD processors automatically treat @type: "@id" strings as IRI references.

The primer also notes that this issue is already recognized:

Note that, for linked-data-aware consumers, the @type of the url property is not strictly aligned with the text of the specification. Namely, it requires an @id value, which may not match with the xsd:anyUri option mentioned in the text.

This creates implementation challenges for ActivityPub libraries that rely on proper JSON-LD processors (like Fedify), which automatically attempt to dereference these URLs as ActivityStreams objects rather than treating them as Link hrefs.

See the discussion at fedify-dev/fedify#420 for a concrete example where this causes parsing errors.

The affected properties likely include all those with:

• Range of Object | Link (or similar combinations)
• Current JSON-LD context definition of @type: "@id"
• Common real-world usage as bare URL strings

Would it make sense to address these properties together with href?

[evanp]

So, the first step to implementing this is to make a future 1.12 version of the AS2 context document available for review and testing. I've made a PR here for that step:

w3c/ns#11

Next, we'll make a CFC for the socialcg to get testing of this new version. Absent any objections, we can make it the default version of the AS2 context after the CFC period.

[trwnh]

I believe I was correct in saying there was a discrepancy, but I believe the original conclusion was incorrect. Essentially, we have two potential ways to address the discrepancy:

• Declare the JSON-LD context to be incorrect, and change it to xsd:anyURI (or drop @type: @id entirely) to match the spec HTML document.
• Declare the JSON-LD context to be correct, and clarify the confusion regarding the HTML document's stated range in a primer page.

Consider an example using as:url and as:href to describe a logical thing and its representations.

This is a possible graph using the current state, or in other words, keeping the JSON-LD context as @type: @id:

@base <https://site.example/>.
@prefix rel: <https://www.iana.org/assignments/link-relations/>.
@prefix as: <https://www.w3.org/ns/activitystreams#>.

<foo>
  as:summary "There are two representations: HTML, and Turtle.";
  as:url
    [as:href <foo.html>; as:mediaType "text/html";],
    [as:href <foo.ttl>; as:mediaType "text/turtle"; as:rel "describedBy";].

# These additional statements are connected to the Link nodes in as:url.
<foo.html>
  rel:alternate <foo.ttl>;
  rel:canonical <foo>.
<foo.ttl>
  rel:alternate <foo.html>;
  rel:canonical <image>.
<image> rel:alternate <image.png>, <image.jpg>.

If we instead say as:href is a literal value whose lexicographical form is datatyped as xsd:anyURI, then we might have the following graph instead:

@base <https://site.example/>.
@prefix rel: <https://www.iana.org/assignments/link-relations/>.
@prefix as: <https://www.w3.org/ns/activitystreams#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

<image>
  a as:Image;
  as:summary "An Image with two representations: a PNG, and a JPEG.";
  as:url
    [as:href "https://site.example/image.png"^^xsd:anyURI; as:mediaType "image/png";],
    [as:href "https://site.example/image.jpg"^^xsd:anyURI; as:mediaType "image/jpeg";].

# These statements are now disconnected from the Link nodes in as:url.
<image.jpg> a _:Resource, _:ImageFile;
  rel:alternate <image.png>;
  rel:canonical <image>.
<image.png>
  rel:alternate <image.jpg>;
  rel:canonical <image>.
<image> rel:alternate <image.png>, <image.jpg>.

The semantic question being asked here is, "does a Link's href refer to the Resource, or does it have a Literal value?"

RFC 8288 "Web Linking" defines the Link Target to be a URI-Reference: https://datatracker.ietf.org/doc/html/rfc8288#section-3.1

One practical consideration here is that a Literal **WILL NOT** resolve against a base URI, but a URIRef **WILL**.

@base <https://site.example/>.
@prefix as: <https://www.w3.org/ns/activitystreams#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

# This WILL NOT expand against @base.
<image>
  as:url
    [as:href "image.png"^^xsd:anyURI;],
    [as:href "image.jpg"^^xsd:anyURI;].

# This WILL expand against @base.
<image>
  as:url
    [as:href <image.png>;],
    [as:href <image.jpg>;].

Conclusion

Given all of this, I think that the context document is actually correct, and should not be changed.

To clarify confusion, we can:

Needs Errata

AS2-Vocab should say that as:href has a rdfs:range of rdfs:Resource, not xsd:anyURI.

Needs Primer

Explain the difference between Literal and non-Literal, because it matters elsewhere too.

When the JSON-LD context defines @type: @id, this should mean that the value is a "Thing" and not a "String". More precisely, it is an IRI or URIRef: an rdfs:Resource that is not an rdfs:Literal.

The difference between rdfs:Resource and xsd:anyURI is that a Resource is the thing being linked to, while xsd:anyURI is the literal sequence of characters that make up its URI. It's the difference between <foo> ("the thing I call foo") and "foo" (the literal string composed of the characters "f", "o", "o").

Close the PR at w3c/ns#11

Changing the context document would be incorrect, as discussed above.

[evanp]

There was a change in the recommendation for this issue. I actually think using a URI for href is correct, so I'm going to let this one bubble for a while.