parameters to the TEI media type (generalizing their usage + a repository)

[bansp]

This ticket is probably the first of a group of tickets -- I am trying to split my thinking into issue-able chunks. It should be seen as somewhat related to issue #564, and in more than one way. It is to some extent parallel, but later on I am going to ask about points of contact.

---

My thoughts have recently been circling, sometimes whirling, around RFC6129 "The 'application/tei+xml' Media Type" and the consequences of its introduction. In this ticket, I would like to fly two questions/issues by the Council, but first let me provide more context:

• TEI is one of the recommended encoding formats (or toolkits for defining formats, we know the rote...) within CLARIN ERIC, the language-resource-oriented European Research Infrastructure.
• CLARIN offers various web services, and among them is the system that you again might have heard about, namely the configurable pipeline system called WebLicht. Weblicht can ingest 'plain' TEI and output an annotated version, and you decide what exactly is chained in this pipeline and in what order.
• CLARIN features various encoding formats, and among them is the most recent product of ISO-TEI cooperation, namely the format for encoding speech transcription. It’s a TEI ‘flavour’.
• Another format in wide use is that of the German Text Archive (Deutsches Text Archiv, DTA). It’s also a TEI ‘flavour’.
• Both formats are ingested by WebLicht pipelines and operated on, in different ways. I have summarized the basis for the current practice of "flavour detection" in a wiki article, with a title not restricted to CLARIN, for a good reason (and while you're looking there, allow your gaze not to rest on the tokenized parameter; it might make an appearance in another ticket). WebLicht knows which TEI flavour it is ingesting thanks to an extension of the TEI media type, namely parameters, and currently it looks like this:
  • application/tei+xml;format-variant=tei-iso-spoken for speech transcription
  • application/tei+xml;format-variant=tei-dta for DTA

Now the promised two questions:

• wouldn’t TEI Simple (together with TEI-for-jTEI, and others) qualify as yet another flavour that could/should be recognized by services in an analogous way? (please note: this not meant to solve issue #564 -- it's merely a point of contact)
• a bit independently of the decision on the issue above, wouldn't it be cool if the TEI had a central repository of such parameters to its definition of media type, so that there exists a reference point, and a place where this can get registered and kept together for minimally, verification and curation?

(And I itch to mention that this information should reside either in ODD or in the header, or in both. But let's keep that for a separate issue or for discussion inside issue #564.)

[bansp]

To be sure, I can think of several other TEI annotation formats ('flavours') that may benefit from this, whether or not Simple gets the stamp. It's just that my direct expertise is limited to linguistic annotation formats but it's obvious that the solution is generalizable across the TEI.

[laurentromary]

This seems like a sensible move. If council agrees with this, we could think of revising the TEI media type document accordingly, since your proposal seems to impact (parameter?) on it.

[bansp]

Indeed, a sensible move would be to first gather the information and gauge the interest of the community. I'd rather do that with the Council's blessing or at least approval. If Sigfrid is not available for the IETF task then I will be glad to help out.

[hcayless]

I'm tempted just to say "go for it, @bansp". This seems a potentially useful thing, but I've no idea what the level of interest might be, and it would be good to start there. Any objections or input from other Council members?

[emylonas]

Similar discussion took place with respect to identifying schemas and resulted in proposal for schemaRef. This proposal provides a way for applications to avoid looking in the file for for schema information, which is very useful. Council thinks Piotr should go ahead.

[bansp]

Thanks! :-)

[bansp]

I have opened a project for this issue at https://github.com/orgs/LingSIG/projects/5 There is also a project at https://github.com/clarin-eric/standards/projects/2 (apologies if they are inaccessible -- it has been reported to me that one apparently has to be a member of a team in order to see projects, even in open repositories)