fix(cite-as): claim it only on the page a nanopublication resolves to - #717
Open
ashleycaselli wants to merge 1 commit into
Open
ashleycaselli wants to merge 1 commit into
ashleycaselli wants to merge 1 commit into
Conversation
rel="cite-as" (RFC 8574) says which IRI the page being read is to be cited as. It sat in the markup of the SourceNanopub panel, which is the general "link to a source nanopublication" and renders wherever one is linked -- once per item in ItemListElement, for instance. A page listing n nanopublications therefore made n conflicting claims about itself, none of them its own identity, and a link to another item's source made a wrong one even on a single-item page. For dokieli, the reason #633 added the link, that is worse than not having it: an annotation would anchor to whichever nanopublication happened to be linked. Pages now say what they are to be cited as through getCiteAsIri(), which answers nothing unless the page is that resource's own page. ExplorePage answers with the nanopublication's IRI when the explored id resolves to one. Rendered into the head rather than onto the visible IRI link. A rel is a list of tokens and every token resolves against the vocabulary in scope, so putting the vocab on the visible link -- which carries noopener noreferrer for its target -- would assert two further link relations about the page. A link of its own carries the relation and nothing else. Closes #716 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NnGpEQkFqCaf4AEQwwhFFn
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #716. Follow-up to #633.
The problem
rel="cite-as"(RFC 8574) says which IRI the page being read is to be cited as. It lived in the markup of theSourceNanopubpanel:That panel is the general "link to a source nanopublication" and renders wherever one is linked —
ItemListElementcreates one per list item. So a page listing n nanopublications made n conflicting claims about itself, none of them its own identity, and a link to another item's source made a wrong claim even on a single-item page.For dokieli — the reason #633 added the link — that is worse than not having it at all: an annotation would anchor to whichever nanopublication happened to be linked on the page rather than the one being read.
The change
NanodashPage.getCiteAsIri()— a page says what it is to be cited as, and answers nothing unless it is that resource's own page. The default is nothing, so every page that merely links to nanopublications is silent.ExplorePageanswers with the nanopublication's IRI when the explored id resolves to one.SourceNanopubgoes back to being a plain link.Why the head, not the visible IRI link
#716 suggested hanging it off the visible IRI link, and I started there. It doesn't work cleanly: a
relis a list of tokens and every token resolves against thevocabin scope. That link carriesrel="noopener noreferrer"for itstarget="_blank", so putting the vocabulary on it would assert two further link relations about the page —relation#noopenerandrelation#noreferrer— alongside the one we want.A
<link>of its own carries the relation and nothing else, is what Signposting recommends for an HTML landing page, and is still RDFa-visible so dokieli reads it the same way. It also makesabout=""unnecessary: the subject falls back to the document, which is exactly the claim. Rendered:Testing
CiteAsLinkTestrenders pages throughWicketTesterand asserts against the markup: a resource's own page claims exactly onecite-aspointing at itself, with the vocabulary in scope and no other relation on the tag; a page without a subject of its own claims nothing.CiteAsSubjectPageis a test-only stand-in so none of this needs a nanopublication over the network.Full suite: 1439 tests, 0 failures.
Note
#716 asked whether a pinned-version or
?ref=-scoped rendering still counts as "the page it resolves to". This takes the straightforward reading — the page claims acite-aswhenever the explored id resolves to a nanopublication — which is right for the redirect target that motivated #633. If a?ref=-scoped view should stay silent, that is a one-line change togetCiteAsIri()and worth deciding separately.🤖 Generated with Claude Code
https://claude.ai/code/session_01NnGpEQkFqCaf4AEQwwhFFn