I saw it more as “alternate representations of the content on this page”. MDN says of canonical:
Preferred URL for the current document.
So at:canonical would be like “the preferred AtURI when referring to this page”. The “if you gotta choose one, this is the most appropriate”.
Alternate is:
Alternate representations of the current document.
So this is other AtURIs the current document could represent. Imagine for example a page that has a blog post but the website (or post) is also about a certain event. You could use at:alternate to indicate that the page is also representing an event. It doesn’t say too much about what the relationship is, but it gives a hint. If you drop that page in a event viewer, it can choose to use the hint to e.g. let you RSVP.
Making a at:publication (or at:standard.site:publication) still remains open as future extensions! People may try to use the more precise type if/when one exists, but it’s good to have a generic fallback so there isn’t an explosion of types just because. The ecosystem already ““knows”” (or is trying to figure out) how to handle NSIDs, and this is a way to help them find them by looking up simple properties. Then it may also help add more precise context where there’s available grammar (e.g. me vs author) not representable in the record itself.
I don’t think we should hurry into a bunch of namespaces/properties that we don’t have a discoverability or grammar history for, especially when they just duplicate existing info. It doesn’t feel impossibly harder to aggregate at:alternate and get the NSID (and we can add data- properties to help), but it will spare us a lot of chaos and confusion in the future.
You can try to mandate one, but I think the history of the web shows “people will be people and there’s a vested interest in being accommodating”. The old software adage “be liberal on what you accept but precise in what you return” comes to mind: there should be The Preferred Format™ (I’m for consistency, so all with at://), but enforcement may be less strict.
I’ll add another +1 liking the at:canonical and at:alternate proposals, but I think that current usage I’ve seen of the site.standard.document property in link tags is intentionally different.
I agree with how you’ve defined canonical and alternate, which is representative of the historical usage beyond atproto. I expect that some services will interpret both of those as indications that instead of sending a user to that page, they should direct the user to a rendering (either within that service or on another app) of the atproto content. This is a great flow when the lexicons can be natively supported, and is currently how bsky.app links (who’s pages set the alternate link tag) are handled in mu.social - it just opens mu.socials rendering of that page rather than sending the user to the actual page linked.
But I’ve also seen many blogs use this alternate meta tag, and I’m not sure if they would be expecting mu.social to do the same thing if mu.social started natively supporting rendering this site.standard.document lexicon. Especially with the current state of analytics in atproto, the author get’s something tangibly different depending on where the content is consumed. So I think we still need another “base” property (e.g, at:related) to indicate the connection to the post (validating 2-way linking, etc) without impacting user flow. We could say then they should continue to use the lexicon as the property (like is done now with site.standard.document), but I think there is value in having a unified cross-lexicon version.
Close to finishing a draft of this community protocol and a small reference implementation/test suite. In the mean time I did stumble upon some more history about this topic:
older discussion about a atprotocol:creator property. semble is using tag <meta name="atprotocol:creator" content="at://did:plc:bnqkww7bjxaacajzvu5gswdf">
Frontpage is also adding<link rel=”alternate”> with at URIs.
I want to second my strong interest in element tagging, which I admit is somewhat out of scope, but also, it seems like this is such an elegant way to get both!
I filed at-tags#1 before seeing the discussion here.