Re: [tei-council] xenodata/@scope

Hi Fabio, Many thanks for laying out some real use-cases that will help us see the bigger picture. I think #3, #4, and #5 all present an issue that we can make a straightforward decision on: Is it OK/encouraged/supported to point between subelements inside the XML content of a <xenoData> and elements in the TEI content? I would say: Yes, why not, when the <xenoData> contains XML. Since there's no knowing what xenoData is, the only thing we can give examples of really is pointing from TEI to @xml:id attributes inside <xenoData> (or using similar pointing mechanisms such as XPointer). But if the other flavour of XML has its own pointing attributes, they could perfectly well be used with the caveat that the encoder understands them and can cause them to be processed correctly. When the <xenoData> content is not XML, it's also possible (although very messy) to use e.g. XPath to point from a TEI element to it. I don't think we'd ever want to encourage this or give examples of it, though. I would, though, tend to recommend that where possible, each block of non-TEI data be in its own <xenoData> element, and that any pointing take place between that element and the TEI content. That's simpler and cleaner, if it's practical. Cheers, Martin On 15-10-08 12:27 PM, 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