OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Metadata subcommittee discussion



Patrick Durusau <patrick@durusau.net> wrote on 02/02/2006 11:15:21 AM:

>
> To some degree it is hard to separate scope/goals from the issue of
> having the subcommittee. I would probably feel differently than I do if
> the goal was to re-write the Cyc ontology.
>
> Suggestions welcome! Please post to the list.
>

I'm not an metadata person per-se, but here's some thoughts/questions:

I tend to think of meta data as being of three types:

1) Fixed-schema like Dublin Core, a fixed set of bibliographic values which apply to the document overall.  This is what ODF has today.   Rigid, but you always know what to expect.

2) Meta data to support semantic layering.  I'm thinking of cases where there is a predefined schema for a particular use or industry which can be used to annotate a document.  So, someone doing critical commentary on ancient Greek texts might use one metadata schema, but a lawyer reviewing testimony might use another.  A single document might allow users to load multiple, pluggable metadata schemas to allow multiple layers of semantic information at the same time, which a clever editor could use via color coding, interlinear markings, etc.

3) Free, ad-hoc use.  Users can right click on any content or select and add metadata in arbitrary schemas.  Or we allow arbitrary content as child-elements and attributes of all ODF-defined markup.  Any given editor may or may not understand these additional elements, but they are obligated to save them back when the document is saved.

So what are we trying to do?  A better way of doing #1?  A way to move to #2 and at the same time redo #1 so it is more harmonious with how we do #2? Something else?  If there is more of a consensus on part of this than the whole, then maybe break it into stages.

Also, "tagging" is becoming popular, with flickr, del.icio.us, etc.  Isn't this just metadata?  Should we add a place for this?  

Also, at the package level are we sufficiently flexible?  Not quite metadata in the way we've been thinking about, but what if an editor wants to store an extra file in the zip?  Does the specification give enough guidance on how to do that.  For example, I might want to bundle up extrinsic metadata in a separate XML document, XLink'ed to content in the main document XML.

Any other use cases?

-Rob


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]