You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A resource part can itself have parts — a paragraph of a documentation topic, an entry of a collection, a term of a vocabulary version — but the part page's breadcrumb knows only one level: super-spaces › resource › part. On the Nanopublication Docs, a paragraph page reads
Nanopublication › Nanopublication Docs › Approval
with the topic ("Person") nowhere in it, although the reader arrived through the topic page and the paragraph declares schema:about that topic.
What already exists
#697 carries the part a link was made from: partPageRef / NavigationContext.withPart add part=<partIri> and part-label=… to every link out of a part page whose target shares the context. ResourcePartPage receives them today, but uses them only for the "‹ back" link on pages without a breadcrumb of their own and for the redirect after publishing. Part pages have a breadcrumb, so the incoming part is dropped there.
Proposal
In ResourcePartPage, insert one crumb between the resource and the current part:
Navigation first. If the incoming part is itself a part of the same context (and is not the current part), render it as a crumb with its part-label: Nanopublication › Docs › Person › Approval. A part that belongs to several parents thus shows the parent it was reached through — the right answer when membership is semantic (schema:about) rather than containment, as it is for documentation paragraphs that belong to more than one topic.
Declared parent as fallback. With no incoming part (direct link, search result), take the parent from the part's defining nanopublication: an IRI it is schema:about or dct:isPartOf that is itself a part of the context. If several, the first; if none, the breadcrumb stays as it is today.
The crumb links to the parent's part page under the same context. Links out of the page keep carrying the current part as before, so the chain extends naturally to a third level if one ever exists.
Nothing changes for parts without a parent, and nothing is docs-specific: vocabulary versions and collections get the same crumb.
Notes
The check "is a part of the same context" can reuse whatever ResourcePartPage already does to resolve the current part (ViewDataFetcher.partDefinitionQueryRef), applied to the parent IRI, or simply trust the incoming part when its context matches, as withPart already guarantees.
getPartLabel() is already used to hand the label along; the parent's label comes from part-label, with the same schema:title fallback feat(views): let a paragraph link to its own part page #703 added for the page title if it has to be resolved.
Problem
A resource part can itself have parts — a paragraph of a documentation topic, an entry of a collection, a term of a vocabulary version — but the part page's breadcrumb knows only one level: super-spaces › resource › part. On the Nanopublication Docs, a paragraph page reads
Nanopublication › Nanopublication Docs › Approval
with the topic ("Person") nowhere in it, although the reader arrived through the topic page and the paragraph declares
schema:aboutthat topic.What already exists
#697 carries the part a link was made from:
partPageRef/NavigationContext.withPartaddpart=<partIri>andpart-label=…to every link out of a part page whose target shares the context.ResourcePartPagereceives them today, but uses them only for the "‹ back" link on pages without a breadcrumb of their own and for the redirect after publishing. Part pages have a breadcrumb, so the incoming part is dropped there.Proposal
In
ResourcePartPage, insert one crumb between the resource and the current part:partis itself a part of the same context (and is not the current part), render it as a crumb with itspart-label: Nanopublication › Docs › Person › Approval. A part that belongs to several parents thus shows the parent it was reached through — the right answer when membership is semantic (schema:about) rather than containment, as it is for documentation paragraphs that belong to more than one topic.schema:aboutordct:isPartOfthat is itself a part of the context. If several, the first; if none, the breadcrumb stays as it is today.The crumb links to the parent's part page under the same context. Links out of the page keep carrying the current part as before, so the chain extends naturally to a third level if one ever exists.
Nothing changes for parts without a parent, and nothing is docs-specific: vocabulary versions and collections get the same crumb.
Notes
ResourcePartPagealready does to resolve the current part (ViewDataFetcher.partDefinitionQueryRef), applied to the parent IRI, or simply trust the incomingpartwhen itscontextmatches, aswithPartalready guarantees.getPartLabel()is already used to hand the label along; the parent's label comes frompart-label, with the sameschema:titlefallback feat(views): let a paragraph link to its own part page #703 added for the page title if it has to be resolved.Follows on from #697 and #703.