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

robert_weir@us.ibm.com wrote:

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

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


There's actually a related thing we might consider that would also
help this sort of conversion: standardizing common style names that
exist in pretty much all markup formats. I'm thinking of stuff for
quotes, blockquotes, body text, emphasis, and so forth.

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

I think so. My own specific recommendation on this in fact comes out of
informal conversations with people associated with the W3C semantic web
initiatives. I absolutely believe we should adopt (or adapt) an existing 
standard, and I think all of us likely agree on that.

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

What about third-party applications?

Also, what if you need to refer to the same metadata description 20
times in a document? Imagine a legal document (let's be grand and say a
brief submitted to the Supreme Court!): one might have embedded
descriptions for case information that is cited in the text. Such a
document might repeatedly cite a single case.

So in the example of 1, you end up with huge duplication, and potential
for inconsistencies.

In the case of three, you need to include 20 additional statements that
associate the description with document content nodes. And if I go back
to my question about third-party tools, my guess is the processing
becomes a lot more hairy.

> #3 has a unique benefit in certain contexts, in that it allows
> annotation of a document which you may have read-only access to.

This is true.

> On the other hand it is fragile, since a change to the annotateddocument 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.

Agreed on all of the above. I wrote the stuff up top before getting to
this, but will keep it there for reference.

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

I agree. In fact, I've written an example of what I'm talking about here
in RELAX NG, and it's worth nothing that in that example there is only a
single element specific to bibliographic metadata (and similar ones for
others), and even that could be removed if necessary. It just types the 
descriptions, and that could also be done with a generic rdf:type element.


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