I'd be interested in Syd explaining why he doesn't think 4a is a good idea? Generally I'm of the opinion that anything inside <xenoData> and its relationship to the electronic text is totally in the hands of the encoder. I think it will definitely be used for non-bibliographic metadata. -J On 04/07/15 16:40, Kevin Hawkins wrote:
All,
Since I created the ticket that prompted this ( https://sourceforge.net/p/tei/feature-requests/453/ ), I hope you'll forgive me for inserting myself into your discussion. I should first say that, in general, I think it's a good idea to summarize Council deliberations of this sort on the tickets themselves in order to get input from the person who submitted the ticket. You don't have to take the submitter's advice, but it may save you trouble in the future in case you end up implementing it in a way that doesn't actually meet their needs.
Anyway, back to the matter at hand.
The Guidelines have always been careful to distinguish between bibliographic information about the electronic document and about the source of that document, making it clear that of the children of <fileDesc>, only the contents of <sourceDesc> are meant to describe the source. As for other components of the header, it's implied that <encodingDesc> and <revisionDesc> describe the electronic document as well, whereas <profileDesc> is unfortunately ambiguous.
It seems plausible to me that someone would want to provide outside metadata describing either the electronic document or the source document, and the Guidelines should provide a way for them to describe either. While we could be ambiguous about which is being described (as with <profileDesc> and Syd's option 1), I think we can all agree that it's better to be explicit.
You could create @describes or use @type (options 2-4), and if so, I think you should add it to <profileDesc> as well. Still, this doesn't feel right to me. The various descendents of <fileDesc>, <sourceDesc>, <bibl>, <biblStruct>, and <biblFull> are used to describe, variously, the electronic document, the source document, or another bibliographic item mentioned in the document, and you only know which of these based on the ancestor element. To follow this practice, I think it would make sense to allow <xenoData> both as a child of <fileDesc> and of <sourceDesc> -- that is, option 5.
But then the question remains whether only allowing <xenoData> to be used to provide *bibliographic* metadata (what's found in <fileDesc> and again in its child <sourceDesc>) is really appropriate. While the Dublin Core, MODS, and Creative Commons examples at http://paramedic.wwp.neu.edu/~syd/temp/TEI_Council/P5-for-xenoData/Guideline... are all purely bibliographic, I'm not sure we can exclude the possibility that someone would want to include external non-bibliographic metadata -- that is, the sorts of data found in <encodingDesc>, <profileDesc>, and <revisionDesc>.
If we follow this train of thought, we'd want to allow <xenoData> to be included *anywhere* in the header so that it would be clear from the parent or ancestor element what the data it contains describes. However, this gets away from the rationale given in http://paramedic.wwp.neu.edu/~syd/temp/TEI_Council/P5-for-xenoData/Guideline... -- that it's "easier for humans to manage these elements if they are grouped together in a single location".
For that reason, I now reluctantly support options 2, 3, or 4a. (I don't support 4b because I think suggested values are always better than not suggesting any values.) I do like the idea of maintaining the TEI's very basic distinction between a description of the electronic document a a description of the source document, so I think it would be good to make this explicit and, as above, to implement a similar solution for <profileDesc>.
Furthermore, I recommend giving an example in the element spec where there's more than one <xenoData> element, each with a different @describes or @type, showing that you might include both metadata about the electronic document and about the source document but that you would be careful to put the metadata in separate <xenoData> elements.
Kevin
On 7/4/15 9:12 AM, Syd Bauman wrote:
First, <xenoData> should be a member of att.declarable. I think that's pretty much a no-brainer, but raise it here in case someone wants to object.
But my next issue is at least non-obvious, if not controversial (and I hope it's not). How is a process to know whether the metadata supplied in <xenoData> applies to the TEI document or to the source thereof? Several possibilities jump to mind.
1) It doesn't. This is not our problem. Any project using <xenoData> will know what metadata they are using, so they'll figure it out just fine.
2) We add a new attribute to <xenoData>, @describes. Its possible values are "source" and "transcription" or some such.
3) We use a special @type (with values "source" and "transcription" or some such) for this, even though it's not quite right.
4) We add <xenoData> to att.typed and let projects come up with their own values of @type to assert this information. Maybe with suggested values (4a), maybe not (4b).
5) Instead of making <xenoData> a member of model.teiHeaderPart, and thus a younger sibling of <fileDesc>, we allow <xenoData> to occur as a child of <fileDesc> or as a child of <sourceDesc> (via membership in model.sourceDescPart). In the former case the metadata in <xenoData> is understood to apply to the TEI document; in the latter case the metadata in <xenoData> is understood to apply to the source from which the TEI document was derived.
6) Like (5), but leave <xenoData> as a member of model.teiHeaderPart instead of (6a) or in addition to (6b) a direct child of <fileDesc>.
Personally, I'm leaning very strongly towards (2), (5), or (6a). That is, I think (1), (3), (4a), and (4b) are bad ideas, and prefer (6a) to (6b). That said, I'm open to thoughts, ideas, and suggestions.
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford