search

TEIC / TEI

The Text Encoding Initiative Guidelines
https://www.tei-c.org
Other
267 stars 88 forks source link

metadata element for header #5

Closed TEITechnicalCouncil closed 8 years ago

TEITechnicalCouncil commented 20 years ago

I would like to suggest adding a metadata element to the header (maybe under profileDesc?) This element would have a series of keys and values; e.g.,

<profileDesc> <metadata> <metadataItem> <key>Provenance</key> <value>Oxyrhynchus</value> </metadataItem> <metadataItem> <key>Location</key> <value>Sackler Library</value> </metadataItem> </metadata> </profileDesc>

This would allow people to use their inhouse scheme, which may not always be compatible with what TEI already has, or extensions like MASTER.

I attach a file (a work in progress) which is an attempt to encode a Graeco-Roman papyrus manuscript. You will see at the bottom of the file my <div type="metadata"> hack to include metadata that I need for the digital library system I am using (Greenstone). It seems to me that this data should be in the header. I did try using the existing conventions, but gave up.

Tim Finney

Original comment by: @tfinney

TEITechnicalCouncil commented 8 years ago

This issue was originally assigned to SF user: louburnard Current user is: lb42

TEITechnicalCouncil commented 20 years ago

Papyrus transcription

Original comment by: @tfinney

TEITechnicalCouncil commented 19 years ago

Logged In: YES user_id=686243

While there is a part of me that likes the idea of permitting open-ended metadata, another voice tells me it's a bad idea. The logic, which I admit is not well thought out, let alone perfect, is that if you have a need for a Provenance field in your metadata, either a) no one else knows about it, so if it's in general-purpose metadata elements it won't get used nearly as much as a defined bit of metadata (although, admittedly more than none, which is the flaw in my logic), or b) others know about it and agree it is useful metadata, in which case I'd prefer that we come up with a particular place in <teiHeader> for it. (I.e., you should be making an argument for a <provenance> element somewhere in <teiHeader>.)

Note that the suggested construct <metadataItem> <key>Provenance</key> <value>Oxyrhynchus</value> </metadataItem> contains the same information as <provenance>Oxyrhynchus</provenance> and clearly one could be transformed to the other quite easily. The advantages, IMHO, of using the latter rather than the former (even if it requires a project to customize the TEI schema) include

Especially if P5 codifies methods for using other metadata standards (e.g. Dublin Core, METS, EAD, whatever) as I believe the Library SIG would like to, I don't think generic metadata is a great idea.

Original comment by: @sydb

TEITechnicalCouncil commented 19 years ago

Logged In: YES user_id=1047169

Thank you for what you have written, Syd.

The arguments you put forward are no doubt incontravertible (sp?). Even so, I remain a heretic and still want the open-ended metadata hack. Here is why (using "I" vicariously for other TEI novices who know only in part but not yet in full):

(1) I don't know what metadata my employer eventually may want -- the requirements change from time to time; (2) I want to be able to do quick and nasty hacks then do it the right way later if worth it; (3) Sometimes a little bit of tag heresy is a good thing. Who knows, you might find this hack will encourage more people to use TEI? (Sly enticement.) Afterwards, keepers of the true faith can lean on the reprobates to purify their TEI (i.e. suggest new tags, have them ratified, then recast their hacky docs to reach the ideal of full interchangability.) (4) The metadata hack is typically for use with in-house systems, which tend to be short-lived. Anything in the hacked metadata that proves itself worthy of being kept through the ages can be given a canonical TEI home.

Maybe think of the metadata hack as a probationary area where potential header-type tags can be tried out? By the way, I set out to use Dublin Core, but gave up trying to bend the metadata requirements of the present papyrology project into the DC shape. Papyrologists want to be able to use a lot of metadata fields (see APIS, for example) -- provenance is merely an example of the desiderata. Things are still in a state of flux. It's the old 20 80 rule -- 20% of the features will be used 80% of the time, etc., etc.

Original comment by: @tfinney

TEITechnicalCouncil commented 19 years ago

Logged In: YES user_id=95949

I'd recommend using a different namespace for this rogue/probabationary metadata

Original comment by: @sebastianrahtz

TEITechnicalCouncil commented 19 years ago

Logged In: YES user_id=1021146

The general question of how to integrate the TEI header with other metadata frameworks needs to be discussed and has been raised with the Libraries SIG. It will also come up at the Members Meeting.

The specific suggestion here of allowing for "probationary" viral elements within the TEI header is an interesting one. I agree with Sebastian, however, that such material probably belongs in a different namespace.

Original comment by: @lb42

TEITechnicalCouncil commented 19 years ago

Original comment by: @lb42

TEITechnicalCouncil commented 19 years ago

Logged In: YES user_id=1021146

The general question of how to integrate the TEI header with other metadata frameworks needs to be discussed and has been raised with the Libraries SIG. It will also come up at the Members Meeting.

The specific suggestion here of allowing for "probationary" viral elements within the TEI header is an interesting one. I agree with Sebastian, however, that such material probably belongs in a different namespace.

Original comment by: @lb42

TEITechnicalCouncil commented 19 years ago

Logged In: YES user_id=1047169

Who am I to keep on with this after SB politely says it is a bad idea and SR and LB both say to use another namespace? Nevertheless, I lunge once more.

Allowing viral elements might not be a bad idea. It all depends on whether you believe in creation or evolution. With creation, God designs the thing and it works. God's creating agents (LB, SB, SR and, to a lesser extent, the SIG servants) understand the whole design and can see what is good and what is evil. Nevertheless, being somewhat less than God, they are not omniscient: there might be things that are good that they haven't thought of yet.

When mere mortals try to use the design, they don't have the knowledge of good and evil. They abuse tags, call for things that are already there, etc. Perhaps the best thing is to encourage them to use the thing, and thereby learn it better. But they are discouraged when something that they want now does not appear to be there. They might try to use an inferior design or even come up with their own. (God forbid!)

With evolution, viral elements are what make the whole thing go. The process takes far longer and there are a lot of sorry mistakes along the way. The end result might have useless appendixes. Nevertheless, advantageous elements get in and natural selection weeds out the rest.

Oh well. Back to the point. I bow to your collective wisdom. If I may beg your indulgence, some of us novices get frightened when we hear words like "namespace" (my ignorance is showing). Maybe P5 could have a primer with a working example on how to do this?

Original comment by: @tfinney

TEITechnicalCouncil commented 17 years ago

Original comment by: @sydb

TEITechnicalCouncil commented 17 years ago

Logged In: YES user_id=1021146

I think that with the general spreading of the class system through the header, (not to mention those scarey namespaces!) we now have ample opportunity for people to experimentally infect it with their viral changes. So I propose to close this request, hoping that you will be able to re-open it again with a specific example of some useful metadata element that cannot be played within the current structure.

Original comment by: @lb42

TEITechnicalCouncil commented 17 years ago

Original comment by: @lb42