Hi all sorry if jump into this late since I was a supporter of xenoData, I
was having some days of relax with my family. I still am favorable with the
idea of having xeno as a repeatable child of teiHeader, and with the idea
of adding it to att.type class. Instead I do not really like the idea of
having a list of suggested value, since the possibilities are quite a lot
(for instance one could use xeno to add PREMIS metatada that refine
revisionDesc, or texhincal metadata for images of manuscript), and many
other thing we can not think of now.
some thoughts:
1) probably it would be good to have a special attribute to state the type
of metadata vocabulary used, in the syle of @MDTYPE of METS, and this could
be typed adopting f.e. mets Endorsed External Schemas list. In this way we
can avoid having any sort of thing insid xeno.
2) we could suggest the usage of @corresp or @sameAs tu say the fqact thata
a xeno element compkly one of the standard TEI metadata elements
3) a good thing is to add to xeno is an attribute to assert that a set of
xeno metadata apply to a specific part of the TEI file: for instance
imagine *I* want to give MODS description of bibliographic items cited in
the text, or give MIX technical metadata of facsimiles images... The types
beasts here can really be many. I have given a look at actual atts but I
have not seen any already existing candidate (except for a misused @ref),
but some of you can have a wider sight than mine. This could also suggest
to have a revers attribute to point at metadata at least in
model.graphicLike members (but this is another ticket).
4) someone would like to point at xeno residing in an external file. This
could be solved
a) again with an abuse of @ref
b) with a new element, say @extMDRef
c) making the content model of xen more complex to allow an alternation of
<ref> and of internal xeno data.
Probably my thoughts exceed the scope of the initial xeno implementation
but I wanted to give an initial shape to some ideas in my head!
f
2015-07-09 4:22 GMT+02:00 Kevin Hawkins
I was just about to write to the list with the same concern about using @type.
As for the value of the attribute (whatever name you choose) ... While "source" is well established in the Guidelines for the thing described by <sourceDesc>, "transcription" is not generally used for the thing described by the other children of <fileDesc>. After all, the Guidelines claim to be equally applicable not only to a manual transcription of a written or audio document but also to an electronic text created through automated means, even from another electronic source. So "electronic text" is often used, as are "computer file", "electronic file", and "electronic work". So maybe the suggested value of the attribute could be one of the following:
electronicText computerFile electronicFile electronicWork
--Kevin
On 7/8/15 9:17 PM, Syd Bauman wrote:
But just to be explicit about this, we are (deliberately) making the same mistake TEI made with @type of <name> and friends: the value of @type here does not describe the type of the element itself or the stuff inside the element, but rather categorizes the type of stuff that the elements inside refer to or describe. (That's why I liked @descirbes better, but if <xenoData> is going to be used for so much more than describing the source and describing the TEI file, that may not be a good idea.)
I'm convinced. I'll put it into att.typed and give it a private
copy of @type with a suggested values include list of "source" and "transcription" (anyone come up with a better term?) and let Martin or anyone else add whatever others seem appropriate.
People can then poke at that.
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- Fabio Ciotti Dipartimento Studi Umanistici, Università di Roma Tor Vergata Presidente Associazione Informatica Umanistica Cultura Digitale