[office] 1/27/2003: Metadata options

[Monica Martin <mmartin@certivo.net>]

I would lean toward option 2 and some additional discussion on metadata.
 
As an important note to this, there was a proposal in an informal
alignment discussion last week in Santa Fe for the Open Forum for
Metadata Registries for a functional convergence approach that likely
will affect some of our metadata assumptions over time (proposal from
Hajime Horiuchi to cohere UN/CEFACT, UBL, ISO 11179, Dublin Core, et al
efforts).  The briefing is not yet available (will be posted there in a
couple of weeks at http://metadata-stds.org/OpenForum2003/
<http://metadata-stds.org/OpenForum2003/> ).
 
As another note relevant to today's discussion on styles, are they
independent of one another and/or mutually exclusive?  I have seen it
done where you have a base type that can allow a selection of a specific
type to be used.  If these styles are independent and not mutually
exclusive, I would say we may have to look at these styles in the
context of a template that specific 'profiles' could be developed.  If
my assumptions are incorrect, I would encourage more discussion on this.
 
On the possibility of multiple 'documents' or document fragments, and
overall, I would encourage use cases be presented starting at the
highest level (top-level elements for example) to structure our work and
the scope moving forward.
 
My goal in presenting these ideas, if relevant and applicable, is for us
to use the lessons learned of work around us, to expedite the process
and mitigate the risk in doing so.
 
Thanks.
Monica
 
 
 
-----Original Message-----
From: Patrick Durusau [mailto:pdurusau@emory.edu]
Sent: Monday, January 27, 2003 7:43 AM
To: Philip Boutros
Cc: office@lists.oasis-open.org
Subject: Re: [office] Metadata options



Philip,

Somewhat later than I had hoped but a quick reply on Metadata options,
including your #6 posted separately.

Philip Boutros wrote:


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.

OK, but of all the options, I think #2 is the best.



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.

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 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.

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 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.

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 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. 
 

Disfavored. See reasoning under #6.

Does predefined vs. user raise the issue of RelaxNG being able to ignore
elements not in its namespace? In other words, would it be useful to
allow a default processing that handles the predefined metadata and
optional processing of user defined metadata?

Phil also posted a 6th option in a separate post:


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.
 

(I replied to this one earlier but suspect it went only to Phil.)

While I would readily agree that there are things that could be done
differently from Dublin Core, whether better or not is an open issue,
but the utility of a metadata definition depends largely upon its
widespread use. The Dublin Core metadata is clearly incomplete for
biblical studies, yet we followed it in the OSIS schema (a joint bible
encoding project of the American Bible Society and the Society of
Biblical Literature). It was not for a lack of opinions or willingness
to start over at the beginning.   But we realized that it would be
better to have hundreds (now) and hopefully thousands (in the relatively
near future) of bible texts with the minimal Dublin Core metadata
(understood by the library community) than to have to build a consensus
around a new metadata standard.

We retained the ability to extend the metadata for a document but that
will always be layering upon the common Dublin Core metadata in every
document.

I well understand the temptation to craft a better or more complete
solution to problems but there are problems that have no complete or
possibly even better solutions for all users. In those cases, my
suggestion would be that we take a workable solution and provide for its
extension.


Hope everyone is at the start of a great week! (Apologies for the
lateness of the reply. I will try to do better in the future.)

Patrick 

-- 

Patrick Durusau

Director of Research and Development

Society of Biblical Literature

pdurusau@emory.edu <mailto:pdurusau@emory.edu> 

Co-Editor, ISO Reference Model for Topic Maps