MHonArc v2.5.0b2 -->
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 metadata3) Metadata has incoming links to the contentIf 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]