Ooh. Those are great examples! For the SKOS one, presumably your skos:Concepts are URIs, right? You could use term/@ref, where @ref contains the URI of the Concept.
On Oct 8, 2015, at 15:27 , Fabio Ciotti
wrote: I share the wider conception of <xenoData>, and that is why I would like a more fine grained way to assert the possible relationships between the metadata it contains and their data objects (that doesn't mean we need to add necessarily new constructs, we can also adapt existing ones - accepting the risk to extend their semantic and intended usage). I suggest some use cases of possible metadata sets that could go there:
1) I have a set of MODS (DC, VRA, etc) data that replicate the (eventually incomplete) data in <sourceDesc>
How can I state this explicitly? @corresp? @sameAs?
2) Similarly, I have a set of Premis metadata that substitute or implement <revisionDesc> (we can imagine a lot of variation on this theme)
3) I have a MIX technical description of images inside <graphic> elements. How can I link each <graphic> with its related metadata? Are we sure @decls is really apt at this
4) a complication of 3) I have a set of MIX technical description for various kind of image formats referred by <graphic>? Shall the TEI enforce that each single set of MIX data should go in a separate <xeno> container? If not how can a single <graphic> element refer to its own set of MIX?
5) I have a non XML rdf triple that define a SKOS based terminology of elements encoded with <term> (or whatever elements). How can I associate each <term> with its SKOS definition?
...
I am not saying that we should support explicitly all the possible use case but, you know, when you open the door of hell, never know who is coming out. I think that most uses of TEI is guided by purely pragmatic concerns, and the Guidelines cannot control how people behave. But we should at least suggest the intended (or best practice) usage - and conversely forbid the not intended one - in a set of fundamental situations, and make this usage as simple and clear as possible. This is why I think that the @scope attribute we have imagined so far is either not enough granular or redundant (inasmuch as all <teiHeader> data are intended to apply to the XML file and its content, and I could argue that this is true also for <sourceDesc>).
f
2015-10-08 19:21 GMT+02:00 Martin Holmes
: <xenoData> is not intended to be a dumping ground where you get to put your JPEG page images or JSON FOAF data or KML snippets. It's intended to be a place to put extracts of either the (non-TEI) metadata you used to generate your TEI header (but want to keep in its original form for some reason), or the (non-TEI) metadata you generated from your TEI header (and want to keep around for later processes, presumably).
That's not how I see it, to be honest. I would put exactly those sorts of things in it (with the exception of JPEGs). I would hope that any data in <xenoData> would be mirrored in some form or another in the teiHeader, but that may not always be practical.
Cheers, Martin
On 15-10-08 09:10 AM, Syd Bauman wrote:
Raff --
No, it would not help at all to make @scope a pointer to a specific element, or to use some other attribute to do the same thing. But worse, it would cause confusion, because (e.g.) if it pointed to <sourceDesc> does that mean that the (non-TEI) metadata is about "the source of this TEI document" or about the <sourceDesc> itself?
The <fileDesc> doesn't point to what its metadata applies to, the <revisionDesc> doesn't point to what its metadata applies to. Why should <xenoData> be different? Well, because we're collapsing two different uses (<non-TEI-description-of-source> and <non-TEI-description-of-this-file>; or /TEI/teiHeader/fileDesc/sourceDesc/xenoData and /TEI/teiHeader/fileDesc/xenoData; or whatever) into one, and differentiating them with an attribute.
<xenoData> is not intended to be a dumping ground where you get to put your JPEG page images or JSON FOAF data or KML snippets. It's intended to be a place to put extracts of either the (non-TEI) metadata you used to generate your TEI header (but want to keep in its original form for some reason), or the (non-TEI) metadata you generated from your TEI header (and want to keep around for later processes, presumably).
Would it help to make @scope a reference to a specific TEI element in the
header, à la @decls? A reference to sourceDesc or msDesc would unambiguously indicate what the xenoData are about (or is equivalent / alternative to). The downside is that there must be corresponding TEI metadata for this to work, but maybe that's not a bad thing?
Disclaimer: I'm jumping into this late, so apologies if this suggestion may appear naive at this point in the conversation.
-- 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 di Studi letterari, Filosofici e Storia dell’arte Università di Roma Tor Vergata President "Associazione Informatica Umanistica Cultura Digitale" (AIUCD) -- 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