Request: notion of views

[geoffroy-noel-ddh]

Hi,

One concept often present in many digital editions is the notion of 'views' or 'treatment' of a text. For instance the same TEI document may be rendered as a diplomatic, semi-diplomatic, interpretive, modernised, ... From a client perspective it makes sense to let the service encapsulate the logic related to selectively exposing only the TEI elements (e.g. expansion, notes) which are relevant to a desired view. This is also convenient when returning other derivative formats such as HTML, where the same source TEI document would be transformed differently according to the requested view.

Logically I would see a view as a level either on top of the citation tree (each view could have its own tree) or below (each reference is viewable in various ways).

Is that a mechanism which is somehow already supported by the specification? If not, has this feature been mentioned or requested before?

I imagine that one roundabout way to implement this with the current specification would be to use the the top level in the navigation for the views, then repeating identically trees under each view (e.g. diplomatic.1 vs semi-diplomatic.1). Another option, I guess, would be to represent the text as a sub-collection with one member document per view. Both approaches seem artificial, introduce unnecessary duplication and also lacks a formal declaration of the semantic connection between the view (i.e. consumer of the API would need to know about that encoding convention).

Thanks

[geoffroy-noel-ddh]

If I'm right that the spec doesn't currently support the notion of views but there is interest in that, my personal suggestion would be to add an optional query parameter to the Document query. Something similar to the format parameter. And also a way for the documents or collections to expose, in the Collection response, which views they support (and what is the default view).

[PonteIneptique]

Hi, I think this is something we already discussed, but we can always reopen this.

Another option, I guess, would be to represent the text as a sub-collection with one member document per view

Now, I think that basically what we decided back in the day. You could have the text as a Document with children being its views, with different ids ( https://distributed-text-services.github.io/specifications/Collections-Endpoint.html#child-collection-representing-a-single-work )

Basically, my approach, which might allow for not cluttering too much the API at the moment, would be to have document id http://my.address.org/mydocument be a Document, with "everything" inside it, with children as views http://my.address.org/mydocument/view1.

This could work in the current API, without modifying anything and keeping the link between the document and the view. Note that, if we need to clarify things down the road, we could map Document children of a Document as Views in terms of type ?

[geoffroy-noel-ddh]

Thanks for taking the time to respond that's very appreciated.

That approach sounds practical enough. And yes, I agree that if it was possible to somehow declare that a member in the collection tree is a view of its parent that would be helpful for a user interface unaware of the conventions of a specific API. From a user perspective, they would typically select a text and then, separately, its 'editorial treatment', rather than having to conceptually switch between two texts (which often share the same metadata, and citation trees). So your last suggestion would enable that sort of logical mechanism in a client app.

Better still, if the spec could provide a field to name the view (otherwise things like 'interpretive' vs 'semi-diplomatic' may be stuffed in the document title, its id (which is a project-specific convention) or expressed with third-party schema). Naming the views in a more formal way would also encourage consistency within a collection.

[jonathanrobie]

As I see it, views are highly application specific, and a client can create whatever views it wants. TEI is extremely flexible, and different but similar implementations may want different views of the same data. For instance, see https://www.greekcntr.org/collation/index.htm, which handles similar issues in a different way than you do.

I don't think this belongs in the API, I think it belongs in the client.

A server-side implementation can certainly do what Thibault proposes above: treat a set of views as distinct subdocuments. But making that work will generally require a server and a client that agree on a particular notion of views.