Closed monotasker closed 7 months ago
My two cents on this : I think you could really easily have one Collection that subsidize into two Resources at the very last moment, based on the citeStructure
you want to show.
Although, I find this idea interesting. I am just wondering if it makes sense to put more weight on the implementers / clients for something that could be resolved as said up there.
During the RC Workshop in Durham, it was decided to supported multiple citation trees, while having a silent
default one.
From an object perspective, CitationTree
are found in the citationTrees
property of a Resource
(in the Collection
and Navigation
endpoint), which is an Array of CitationTree
object. CitationTree
objects contain both a maxCiteDepth
(which was moved from the Resource
to the CitationTree
) and citeStructure
property an Array of CiteStructure
objects.
The first CitationTree
found in the array at the citationTrees
property is the default one, and must not bear an identifier.
From a query parameter standpoint, ?tree
is used both in Document
and Navigation
endpoint. CitableUnit
may have an identifier that can be found in two different CitationTree
, but each CitableUnity
identifier must be unique within a CitationTree
.
?tree
must not be used to access the default CitationTree
See #228 for its implementation details and its apparition in the specs.
I'm wondering how we would handle documents that have more than one canonical citation structure. (E.g., the works of Flavius Josephus.) Providers may want to support multiple structures through the API. Can we add an optional parameter to the Documents requests called something like "citescheme" or "citestructure" that would take a string identifying the structural scheme being used for the request?