Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change some endpoints properties from @type: @id to @type: xsd:anyURI #375

Open
trwnh opened this issue May 31, 2023 · 4 comments
Open

Change some endpoints properties from @type: @id to @type: xsd:anyURI #375

trwnh opened this issue May 31, 2023 · 4 comments
Assignees
Labels
Needs Primer Page Needs a page in the ActivityPub primer Next version Normative change, requires new version of spec

Comments

@trwnh
Copy link

trwnh commented May 31, 2023

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
Copy link
Collaborator

evanp commented Oct 4, 2023

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
Copy link
Author

trwnh commented Apr 29, 2024

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

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

@evanp evanp added Next version Normative change, requires new version of spec and removed Postponed (revisit in future effort) labels Sep 20, 2024
@evanp evanp changed the title Should some terms drop @type: @id? If yes, should they set @type: xsd:anyURI? Change endpoints properties from @type: @id to @type: xsd:anyURI Sep 20, 2024
@evanp evanp changed the title Change endpoints properties from @type: @id to @type: xsd:anyURI Change some endpoints properties from @type: @id to @type: xsd:anyURI Sep 20, 2024
@evanp
Copy link
Collaborator

evanp commented Sep 20, 2024

We are leaving this issue open, but only for the specific set of properties in the endpoints array. This should be dealt with in a future version of the AP context document, bringing the context in line with the AP spec text.

Also tagging for a Primer page for how to use @id and xsd:anyURI in extensions.

@evanp evanp added the Needs Primer Page Needs a page in the ActivityPub primer label Sep 20, 2024
@trwnh
Copy link
Author

trwnh commented Sep 20, 2024

Tagging in this StackOverflow answer that has more information about the IRI/xsd:anyURI split

https://stackoverflow.com/a/75603513

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Primer Page Needs a page in the ActivityPub primer Next version Normative change, requires new version of spec
Projects
None yet
Development

No branches or pull requests

2 participants