Open mk-pmb opened 2 years ago
Great list of candidates. I did not know about or look at every candidate you mention, but some thoughts, hopefully of any help:
next-archive
and previous-archive
in RFC 5005 that you mention seem to mean something different than what is intended here.Memento is especially suitable for versioning another party’s resources using timestamped snapshots rather than e.g. sequential version numbers; I now see its spec actually suggests to use RFC 5829 for linking to next/previous snapshots:
“In addition, existing Relation Types may be used, for example, to support navigating among Mementos. Examples are "first", "last", "prev", "next", "predecessor-version", and "successor-version" as detailed in [RFC5988] and [RFC5829].”
Extra reason to go with 5829!
A little update: Our current draft implementation is:
iana:version-history
points to an AnnotationCollection that lists all versions, for each giving at least fields id
and created
. We order them chronologically but that is not an expectation.dc:isVersionOf
is a URL meant to address the annotation without any explicit version preference. In our implementation, that coincides with the URL that is meant as "always latest", which in our implementation always redirects to the version-specific URL of the latest version of the annotation.iana:latest-version
varies by use case and either points to "always latest" (thus coincidingly repeating dc:isVersionOf
) or points to the version-specific URL of the latest version of the annotation (saving the client from having to follow a redirect, if the server can determine that without additional effort).dc:replaces
points to the version-specific URL of the exact previous version.
rel=latest-version
and rel=version-history
.id
field inside the same JSON object.
id
field to be relative:id
.id
of a collection) to the URL that was used to request the collection or single anno.
Our annotation application allows authors to edit their annotations later. We have one URL that always points to the latest version, and each version also has its own specific URL so they can be referenced in citations and comments. Readers should be able to discover that there are older or newer versions available. We thus need a way to associate the various versions with each other. Is there a preferred way?
The obviously least interoperable way would be to create our own Anno Extension. Just mentioning it for completeness.
Better would be to reuse one of the vocabularies defined in the Anno-Vocab JSON-LD Context.
Possible candidates that I found:
dc/dcterms/dctypes: Dublin Core
Possible problems:
iana: Link relations
memento
andtimemap
from RFC 7089 would probably be the most well-defined and thus machine-readable, but on first glance seem cumbersome to implement.Simple Version Navigation (RFC 5829) seems to be an exact match for our purpose.
version-history
andlatest-version
in our case would happen to be the same.predecessor-version
andsuccessor-version
by original definition seem to expect a version exactly one step apart. My idea to make the latest version carry an array of all prior versions asiana:predecessor-version
might be too much of a stretch.memento
, and still as useful, because all relevant time/date information can be read indirectly from the annotations.iana:current could denote the latest version.
last
andlatest-version
current
together withnext-archive
/prev-archive
, alsofirst
/last
andnext
/previous
, but they are meant for news feeds. Not sure how much of a stretch it would be.iana:archives could denote a document that lists versions, which in our case would happen to be the latest version.
index
item and collection are too generic.
skos: Simple Knowledge Organization System
These sound valid solutions but are less specific than
dcterms:*
.Other
rdfs:member
andrdfs:seeAlso
but too generic.