Should some terms drop @type: @id? If yes, should they set @type: xsd:anyURI?

[trwnh]

In #368 I tangentially asked if the various endpoints should be @type: @id or perhaps something else like @type: xsd:anyURI or the default @type: @value.

@id is specifically intended for linked data nodes on the linked data graph. The endpoints defined in the normative context all use @type: @id, but as far as I can tell, they are not intended to be nodes on an RDF graph.

Example expansion with either default type or anyURI type would look something like this:

"https://www.w3.org/ns/activitystreams#proxyUrl": [
  {
    "@type": "http://www.w3.org/2001/XMLSchema#anyURI",  // this would be left out
    "@value": "https://example.com/proxyUrl"  // this would currently be id instead of value
  }
]

Some other terms are also questionably not pointing to node identifiers.

---

In summary, we consider the following endpoints:

• uploadMedia
• proxyUrl
• oauthAuthorizationEndpoint
• oauthTokenEndpoint
• provideClientKey
• signClientKey
• Exception: sharedInbox actually should be kept as @id because it refers to something that is in theory an OrderedCollection node.

And also the following properties:

• href is explicitly only xsd:anyURI (per AS2-Vocab range). It should probably be defined as such in the normative context.
• url may be a Link node but it may also be xsd:anyURI (per AS2-Vocab range). I am not sure how this should be expressed in LD. An array is incorrect since it implies both. I don't know how to properly define "either-or" or "any of" types.
• alsoKnownAs is intended to provide aliases for the same node, not point to other nodes. I'm not sure what this implies for typing.

[evanp]

So, this is a good point; changing those values to a xsd:anyURI would make some sense and avoid some possible mistakes. This is exactly the kind of technically normative change, supported by the text of the specification and common usage, that an updated version of ActivityPub should include. I'm marking this as "postponed" so that we remember to review it if a working group for AP is chartered in the future.

[trwnh]

partial update now that i know more about JSON-LD/RDF

• the "solution" to either-or types is to define multiple terms, each with their own metadata. See items and orderedItems for example. the latter is @container: @list while the former isn't. (tangentially, the former should be @container: @set` to avoid a related issue where a single item can lead to coercing the array out completely during compaction)
  • related issue orderedAttachment (and orderedTag?) activitystreams#537
  • other related issue Force non-functional properties to always be arrays activitystreams#535

so the proper thing to do seems to be

• define href as xsd:anyUri (it already is in the spec, it's just the context document that is "wrong" and needs fixing)
• keep url as type:id, and either:
  1. define something like urlValue that is typed as xsd:anyUri as well
  2. expand the domain of href to be applicable to Object as well (since the above hypothetical urlValue would be near-identical to the existing href, it just has a different id)
  3. make a guidance (mostly for producers) that url points to a Link node, always. (tangentially, this deals with a related issue How should it be interpreted when a URI value is received? activitystreams#498 where there is ambiguity on whether a uri value encountered is a value or a Link; it is always a Link, and ought to resolve to a node when fetched with content negotiation)

i think 1+3 would be best. but this is an issue more for activitystreams than it is activitypub, so i'll file these two points there