#4 metadata element for header

closed
6
2006-09-25
2004-05-22
No

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

Discussion

  • Anonymous - 2004-05-22

    Papyrus transcription

     
  • Syd Bauman

    Syd Bauman - 2004-09-18

    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
    * that it can easily be validated that the key is
    "provenance" not "provennance" (yes, there are methods of
    validating the generic, but not using schemas generated by
    the TEI system);
    * that the new metadata item can be put somewhere in the
    header that makes sense, e.g. be a child of <publicationStmt>;
    * that there is a predefined mechanism (the TEI ODD
    customization system) for documenting its semantics.

    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.

     
  • Anonymous - 2004-09-20

    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.

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2004-09-20

    Logged In: YES
    user_id=95949

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

     
  • Lou Burnard

    Lou Burnard - 2004-09-22
    • priority: 5 --> 6
     
  • Lou Burnard

    Lou Burnard - 2004-09-22

    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.

     
  • Lou Burnard

    Lou Burnard - 2004-09-22

    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.

     
  • Anonymous - 2004-09-23

    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?

     
  • Syd Bauman

    Syd Bauman - 2006-09-25
    • status: open --> pending
     
  • Lou Burnard

    Lou Burnard - 2006-09-25
    • assigned_to: nobody --> louburnard
    • status: pending --> closed
     
  • Lou Burnard

    Lou Burnard - 2006-09-25

    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.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks