mromanello
commented
4 years ago Hi @PietroLiuzzo, many thanks for this proposal. As someone who has recently developed a completely custom JSON API for the index locorum (i.e. index of cited passages from primary sources) of a scholarly publication, I'm very interested in defining ways to standardize how indexes can be exposed and queried.
Here some initial thoughts/questions triggered while reading your ideas above:
-
are the indexes global (= at collection level) or rather one index per dts document? Would it be possible to allow both? (which does not mean a DTS provider must necessarily implement)
-
in
dts:attestationit would be useful to allow for custom RDF statements, for example to assert that "my"Bakaffahas a corresponding entry in e.g. Wikidata, or that a given place has a corresponding entry in Geonames or Pleiades. The use case for this request is the aggregation of indexes across several DTS endpoints; common identifiers provide one possible way to automatically establish identity of entries in multiple indexes (Bakaffain the index of names of doc A is the sameBakaffaas in the index of names in doc B). -
always for the same use case of aggregation, it'd be useful to expose index types as terms defined in the
dtsnamespace (working as a controlled vocabulary) rather than leaving this as a free text string. Well, at least the most common index types (index of place names, index of people, index locorum, etc.) -
are nested structures allowed in
dts:attestation? For an index of citations, it'd be useful to group all document passages citing lines of the Iliad under Homer > Iliad, and then by book, etc.
PietroLiuzzo
PonteIneptique
balmas
Dear all, I have been thinking about a possible additional API, which I will temptatively call indexes Endpoint which I am quite sure has been planned many times and perhaps discarded or deferred to the future. I am not sure and I thought it harmless in any case to copy here my thoughts.
I was thinking of a syntax like the following, to have an API which is index-like and allows a navigation of the text which is not only the structure of it, just like in most cases we would anyway have, and be generic enough not to restrict it self to any particular type of index.
would lists the available supported indexes with their names, depending on what one has marked for such indexes, for example terms, persons, dates, whatever.
Here is a made-up example for a non-readable collection
and one for a readable collection, where additionally I would get direct access to other endpoints, and may find more indexes specific to that only.
Once one has picked the wanted index, this would have the structure of a normal book index with a key and the passages it is found at, optionally also the actual string annotated, if relevant (it would not mean anything for an index of topics for example)
would return the desired index. for example, something like
would have pagination has the collection endpoint and then a number of "attestations" one for each indexed thing. Each of these attestations would come with a series of members, like in the navigation endpoint, for each occurrence in the collection.
I am not sure if it would be useful to include also, &level=2 and &groupSize=2 to determin t the format of ref and return them as "dts:citeDepth" and "dts:level": 3.
In the special case of places, I think it would be also useful to link to pelagios annotations, with a property for that like in the following
I think here
@valuecould also be used also if the document api supports CTS like syntax to get passages likeurn:dts:betmas:LIT4633Chronicle:2@ደብረ፡ ወህኒ፡[1], or eventually if one, starting from this wants to get directly to the forms attested. I have not added totals for the number of attestations, although it would be useful perhaps.I think this type of API would allow a very flexible access to the text in one of the most common ways to access texts normally in books or web resources.