Leigh Dodds has posted the first of two pieces on his take on XMP and (to lesser extent) OpenDocument.
I’d like to return to Alan’s Lillich’s post to the OASIS ODF TC list, and focus in particular on my own answers to a series of smart questions he raises:
How quickly to move on new metadata?
It is essential to get the metadata support right. This could be reasonably done for the next major release of ODF.
Will the new metadata allow open extension?
How are formal schema used? Must end users provide a formal schema in order to use new metadata elements? If not required, is it allowed/supported?
The OpenDocument schema should provide standardized vocabulary support for both Dublin Core and Qualified Dublin Core, which would support the vast majority of metadata needs in ODF. For the bibliographic metadata support that we at the OpenOffice Bibliographic Project need–which is quite demanding–that default support should cover roughly 80% or so of our needs.
The schema should also define the option to include content from other namespaces, based on certain constraints (more below).
If formal schemas are used, what is the schema language? RELAX NG is clearly a better schema language than XML Schema. Can XML Schema be used at all by those who insist on it?
OpenDocument is defined in RELAX NG, and XML Schema is not an appropriate language to define any kind of RDF model. It simply is not expressive enough. The most serious problems with XML Schema is its lack of support for unordered content models, and its weak support for attribute-based validation.
While I expect that it might be possible to define somewhat looser XML Schema representation, RELAX NG ought to be the core language, as it already is in ODF.
What is the formal model for the metadata?
RDF, with some constraints.
Is the formal model based on RDF, or can it be expressed in RDF? If
so, does it encompass all of RDF? If not all of RDF, what are the
model constraints? Can any equivalent serialization of RDF be used?
The formal model is RDF, but removes support for reification.
Does the formal model have a specific notion of reference?
Yes. This is central to the RDF model in fact, and a major limitation to remove it.
If so, does it work broadly for general local file system use, networked
file use, Internet use?
At minimum, the model should enable local (in the file wrapper) linking, which suggests support for rdf:nodeID. This allows use of relative URIs.
What happens to references as files are moved
into and out of asset management systems?
If all metadata is embedded in the file wrapper and reference is relative, then there is no problem.
The question of extra-file-wrapper linking would also be valuable to explore, though perhaps ought to be considered a separate question, because it adds complexity.
What kinds of “user standard” metadata features are layered on top
of the formal model? Users want helpful visible features. They
generally don’t care if things are part of a formal model or part of
conventions at higher levels. For example, a UI can make use of
standard metadata elements to provide a rich browsing, searching, and
This is an implementation question that is somewhat separate from the details discussed above. However, certainly a GUI editor ought to be able to support:
- basic string literals
- ordered sequences
- option to link to full resources: person objects, controlled subject vocabularies, and so forth
How important is interaction with XMP? Is it important to create a
document using OpenDocument then publish and distribute it as PDF?
It is important, but not at the expense of the unique needs of OpenDocument.
If so, how is the OpenDocument metadata mapped into XMP in the PDF?
Simple transform via, for example, XSLT.
Is it important to import illustrations or images that contain XMP into
If so, how is the XMP in those files mapped into
the OpenDocument metadata? How does it return to XMP when published
In general, OpenDocument metadata should be expressed as an XML-tool-friendly RDF/XML subset, embedded as a separate files in the ODF wrapper (and therefore integrated into ODF’s existing packaging mechanism) so that metadata can be accessed in simple and consistent ways with a variety of tools. Indeed, one of the OASIS OpenDocument TC’s explicit charter goals is that it
must be friendly to transformations using XSLT or similar XML-based languages or tools, and this must be true of the metadata support as well.
Ideally, then, their should be some mechanism to extract and embed XMP, and convert between it and the ODF metadata.
How important is interaction with other forms of metadata or other
metadata systems? What other systems? How would the metadata be mapped?
It is very important that ODF metadata support be suitable for integration with other tools, such as external metadata servers. If those metadata servers happen to be RDF stores, there may be need to massage such RDF/XML metadata into the RDF constrained subset.
Are there things in XMP that are absolutely intolerable? Things
that have no reasonable workaround? Does XMP place unacceptable
limitations on possible future directions? Are there undesireable
aspects of XMP that can reasonably be changed?
What XMP brings to table is embedding RDF metadata in binary files. I don’t believe it provides, in its current form, a compelling model and format for OpenDocument. To quote Leigh:
… XMP is … an RDF profile of sorts, although it opts for some rather quirky restrictions on the allowed RDF/XML syntax. Syntactic profiles of RDF don’t scare (or surprise) me, but this one left me with raised eye-brows. Rather than constraining the syntax to a fixed XML format, one that could be validated against an XML schema but still retain an RDF interpretation, the restrictions are placed elsewhere…. I think there are some benefits being lost here. It wouldn’t take much to bring the XMP and RDF models closer together, and still gain the benefits of both predictable structures for applications and the RDF model itself.
I believe this is crucial. The restrictions XMP places on the RDF model–where it throws out much of what is useful in RDF–are really not where the problem in RDF is. The problems are mostly to do with the too-flexible syntax of RDF/XML, which is easy enough to constrain with RELAX NG.
update: Leigh just posted part two, which is more directly about OpenDocument.