[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [office] Metadata options
OK, but of all the options, I think #2 is the best.Hi
I thought I'd start the ball rolling on metadata in advance of Monday's call. Please forgive the "schema by example" nature of my examples. I would have presented the suggestions in a schema language (DTD, XSD, RelaxNG) but I'm not sure we've decided on one yet.
General thoughts
The metadata model presented in OpenOffice.org XML File Format 1.0 (OpenOffice) is somewhat specific to the OpenOffice applications and should probably be made more generic and flexible.
Option 1
Leave it alone.
Preferred since it allows user to extend the metadata in a way would allow validation of the metadata, if I am reading the proposal correctly.Option 2
Leave the existing predefined metadata (meta:generator, dc:creator, etc.) as they are but extend meta:user-defined so it can contain more than just text types. This might be done by typing the element name like this (Note: This example is not intended to be my suggestions for the actual tags and attributes we would use but rather to illustrate the concept):<meta:user-defined-date name="checkin-date">2003-01-24T13:47:12</meta:user-defined-date>
<meta:user-defined-text name="foo">Some text</meta:user-defined-text>
etc.
Doing this would also require type extending text:user_defined to allow formatting of typed user-defined fields like this:
<text:user-defined-date text:name="checkin-date" text:date-adjust="123" text:fixed="true" style:data-style-name="ABC">01/24/03</text:user-defined-date >
<text:user-defined-text text:name="foo" text:fixed="true">Some text</text:user-defined-text>
etc.There are probably other good ways to do this depending on which schema language we go with.
Not at all certain of the criteria for "EVERY document" anymore than how to build "an exhaustive set" as is mentioned in #4. Good example but are there any others that you see as "OpenOffice application" specific?Option 3
Same as Option 2 but with the predefined metadata elements limited to only things we think EVERY document needs. For example meta:template is very specific to the OpenOffice application and should probably not exist in a more generic specification. The OpenOffice application could then add its template metadata it using meta:user-defined-text or meta:user-defined-url.
As mentioned under #3, I am not sure how such a list could be generated nor what the criteria would be for inclusion. For example, biblical scholars would love to have hands (in the TEI sense), joins to other texts (if fragments), etc., but I don't know that predefined metadata elements for such purposes would be of common enough interest to justify their inclusion. Broad categories of metadata might reduce the number but the broader the categories the less useful the metadata.Option 4
Same as Option 2 but extend the predefined metadata elements to an exhaustive set that fits almost every user's needs. This would leave meta:user-defined as a very last resort.
Disfavored. See reasoning under #6.Option 5
Move away from predefined metadata completely to a model like in Option 2 but for all metadata elements. This has the downside of moving us away from the Dublin core. On the positive side we would not have to deal with the difference between predefined metadata elements and user defined metadata elements, the schema would be more compact and tools to process instances of the schema would be simplified.
(I replied to this one earlier but suspect it went only to Phil.)Option 6
Obviously if we want to move significantly away from the current OpenOffice spec we can look at the wholesale adoption of a metadata schema generated by some other body or creation of a totally new metadata definition from scratch.
-- Patrick Durusau Director of Research and Development Society of Biblical Literature pdurusau@emory.edu Co-Editor, ISO Reference Model for Topic Maps
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC