[tei-council] standoff

[Fabio Ciotti]

> Am 28.11.2014 um 10:19 schrieb Sebastian Rahtz <sebastian.rahtz at it.ox.ac.uk>:
>
>> But it seems fairly incredible that we’d introduce _two_ parallel new children of <TEI>
>> both of which contain standoff metadata. Can’t we have just one <metadata>, with sections for
>> <xenoDate> and for <annotation>?
>>
>> I have a gut feeling that some of the bits of current <teiHeader> might move to the new
>> section. eg <profileDesc>

I agree (and have already said in several occasions)  that teiHeader
should be redesigned. I would support an internal structure similar to
that of METS, with adaptation and the addition of a semantic metadata
container, and allow each container to host "xen"o metadata set. But I
guess that this will be a P6 thing, will not?
For the moment I think that having one container for internal standoff
annotation and inclusion of non TEI metadata is not functional, since
it would mix into one element a bunch of very different things. For
instance I assume that standoff markup is related to parts or
components of the content of the TEI doc, while the other metadata are
related to the whole document (this can be questionable but at a gross
level I think it is true).

For the moment I would do this:

1) add a <standOff> element inside profileDesc (which in part is the
place for semantic metadata stuff) where the encoder can collect all
the standoff annotation stuff (intepr, link etc.)

2) add a <xxxxMetadata> element following <revisionDesc> for hosting
metadata in other schemas/namespaces. Probably it would be good to
have a repeatable wrapper element inside it (<metaWrap>??) to collect
different sets of metadata with different schemas and roles. This
element should bear a couple of attributes, one to specify the role of
the metadata (descriptive, technical, preservation etc.) ant the other
to specify with a closed value list the schema adopted (we can take
those from METS)

My two dollars...

> May I introduce a third possibility?
> What about creating a TEI binary (zip) format (examples being docx or odt)? In doing so we could provide a way for relating all sorts of data/documents/schemas/ODD to a TEI file without polluting the document itself.
> I chatted briefly about this option with Martin during the Duke meeting and Martin added that there is not so bad application support from (e.g.) oXygen for zip containers.
> What do others think?

I don't like this thing. 1) Having a binary container would really be
a problem for portability and preservation and that goes against the
TEI Constitution IMHO. 2) A zip container is a processing thing, and I
don't agree TEI in general as a content representation language should
be concerned with processing.
I would see favorably such a container for TEI Simple, instead, but I
think that it would be really a nice thing to work with ePub people on
that. Reinventing the wheel is never a god thing.

f