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




"Bruce D'Arcus" <bruce.darcus@OpenDocument.us> wrote on 02/02/2006 04:11:57 PM:


>
> 1) we adopt a set of rules for extension. Those rules are likely to be
> RDF or some subset (e.g. XMP).
>
> This gives the predictability you note in the sense of the model, but
> opens up significant flexibility. It's the best of both worlds really.
>

> 2) We define a list of document content elements which can hold an
> attribute (or set of them) that point to metadata descriptions (that
> conform to 1) that are stored in the package (see more on this below),
> or might simply be an identifier uri.
>
> 3)  As with 2, we allow these (optional) attributes to be attached to
> style definitions, so that in tagging content with a given style, a
> user would be adding those richer semantics.
>


OK.  This looks good.  I especially like the power of #3, essentially allowing semantic tagging via a word processor.  For example a template could be written in ODF format with such metadata data which would allow a clever application to export the document in DocBook or DITA format.

>
> My sense is the most controversial part is the precise details of 1. Do
> we adopt XMP as is (with its limitations)?  Do we work with Adobe to
> see if they can address some of these concerns? Do we instead simply
> take the existing ODF metadata support and extend it to support a
> richer subset of RDF? Or do we just say ODF metadata = "RDF;" the full
> model and syntax.
>


Do we have a consensus on the requirements of whatever choice is made?  For example, do we all agree that any external specification which the ODF specification uses should be a de jure standard from a recognized standards body, e.g., W3C/IETF/OASIS/ISO.  


> > 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.
>
>  From my perspective, I would want to say that ALL metadata statements
> would be stored apart from the content file, and the linking would
> happen from content to metadata.
>


There are really three ways of doing this, right?

1) Containment, so metadata as child elements (really a degenerate form of #2)
2) Content has outgoing links to the metadata
3) Metadata has incoming links to the content

If an application writes out the metadata each time the document is written, all three should be equivalent from an application perspective.  #3 has a unique benefit in certain contexts, in that it allows annotation of a document which you may have read-only access to.  On the other hand it is fragile, since a change to the annotated document could break all of your links.   In any case, #3 is probably outside the scope of the discussion since it does not involve a change to the ODF document.  

>
> I am imagining three users collaborating on a paper, each using
> different ODF-compatible applications.
>
> As they write the paper and add citations, the citations and
> bibliography are automatically generated from the embedded metadata.
>
> Because the metadata is embedded, it's also portable. When the users
> pass the document around, the logic is always there so that the
> formatting can be regenerated.
>
> And because the metadata is based on a standard model, it would also
> facilitate interoperability between different bibliographic
> applications.
>
> So authors finish paper and send to publisher.  Publisher can extract
> all that metadata and make it available to search engines and journal
> providers.
>


In your example, you have three different ODF-compatible applications, generating endnotes, etc., from the metadata.  To what extent can the ODF specification enable that versus what work would require higher-level interop agreements between application vendors?  Specifically, we can allow metadata in ODF, and allow it to be associated with content and with styles, but to do the use case you highlight would require that implementations further agree on a particular set of semantics related to the bibliographic domain.  I'd recommend that we draw a clear line between the enablement support we put in ODF, and the additional semantics which vendors and user communities will need to define.

-Rob

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