HI Syd, On 15-07-11 11:03 AM, Syd Bauman wrote:
Hi Martin --
You have a MODS record for one item in your transcribed bibliography, and want to put that into your TEI file? Power to you, I suppose. But that doesn't seem much like the feature OP (Kevin) requested, or the "problem" for which librarians have been asking for a solution for almost a decade.
<xenoData>, IMHO, is intended to make the easy case easy, not to make the complex case possible (in large part because the complex case is already possible -- e.g., you can put <mods:*> as a child of <bibl>, or put it in your <teiHeader> attach it to the <bibl> with <link>).
(BTW, I prefer <link> to @corresp for this because I get to express which block of metadata is derived from which, which I can't express explicitly with @corresp.)
That's a good point; <link/> is a perfectly good solution, although it's less direct.
The easy case, the one which quite a few large projects have expressed a desire for, is to have a consistent place to put the METS record from which the <teiHeader> was derived, or the Dublin Core metadata that you derived from the <teiHeader> for whatever purpose, but don't want to re-generate on the fly.
So I'm inclined not to add another mechanism for attachment to <xenoData>. That said, I still want us all to agree on an easy explicit mechanism to say "about the source" vs "about this TEI file".
Speaking of which, Martin, I'm figuring the Dublin Core OAI example from the _The Colonial Despatches of Vancouver Island_ you posted on the ticket is about the TEI file, not the source, yes?
This is from my previous message on that:
The distinction between metadata about the source document and metadata about the electronic document is very fuzzy a lot of the time. One of the things I'm likely to store in <xenoData> is a block of OAI:PMH metadata which includes the date and title of the original document (source) as well as a list of individuals and places referred to in it (source? electronic?) along with information on the date the file was last changed its canonical URL (electronic). It's really closer to <teiHeader> than to e.g. <sourceDesc>.
MH> Also it may well be the case (presumably) that non-XML MH> vocabularies may be used in <xenoData>.
I, for one, had never envisioned non-XML data inside <xenoData>, and think it would be a bad idea to permit it. (For the same kinds of reasons I'm unhappy with <binaryObject>.)
I don't see how you can do anything about it. If you allow anyXML, anyone can just insert a CDATA section, can't they?
That said, it is not at all clear to me whether the content of <xenoData> should be well-formed XML or if well-balanced XML is sufficient. (The difference being well-formed means that <xenoData> can only have 1 child; well-balanced would permit multiple children.) As I originally wrote it, because the content model of <xenoData> was just the already existing 'macro.anyXML', well-formedness was required. I have recently changed it to 'macro.anyXML+'[1], thus allowing well-balanced fragments.
Notes ----- [1] Not entirely true, I changed it to 'macro.anyXML*', about which I plan to post shortly.
Interested to see why. Cheers,
I don't think we're talking at cross-purposes. Let's take a concrete example. Say I have a bibliography encoded as a <listBibl> in the <back> of my document. I have a <xenoData> element in my header that contains a <mods> block which represents one of the <bibl>s in my bibliography. How do I specify that this block of <xenoData> refers to that <bibl>?
@decls is no help here, surely.
I could do it with @corresp (on <bibl> or on <xenoData> or even on both). But Kevin has expressed some reservations about that which I suspect from previous discussions that Lou would share. (I'd be OK with it, myself.) @sameAs would seem to be a candidate, except that (as almost always with @sameAs) when you look at the definition, it turns out that this relationship is not as same-as as necessary for a proper use of that attribute.
So I suggested another linking option. I don't really mind how it's done, but I do think it's important that people be able to link between their <xenoData> blocks and other elements -- any elements -- in their files. In some cases such as FOAF, the standard itself provides a way to link out from the element to its target:
<foaf:Person rdf:about="#danbri" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <foaf:name>Dan Brickley</foaf:name> <foaf:homepage rdf:resource="http://danbri.org/" /> <foaf:openid rdf:resource="http://danbri.org/" /> <foaf:img rdf:resource="/images/me.jpg" /> </foaf:Person>
but other XML vocabularies may not provide this; furthermore, parsing this requires that you understand the vocabulary in the <xenoData>. Also it may well be the case (presumably) that non-XML vocabularies may be used in <xenoData>. So I think there's a strong case for a method of linking to be available at the TEI leve