[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. Yes. 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? 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. 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 Correct. > 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. Bruce
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]