OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

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


Subject: Reuse of metadata proposal for non ODF applications


Hi group!

There has been earlier some discussion and tendencies about making our 
metadata proposal for packages more modular, more reusable for other non 
ODF applications.
As there were no opinions against this approach, we should come quickly 
to a proposal how this can be established.
Therefore I would like to give a suggestion, how this can be done with 
minimal work-load for our group.


The basic idea is to create from the current proposal document two 
documents:

One new reference specification, which explains the metadata framework 
for package formats without relation to ODF.
This document would reside outside the ODF 1.2 specification.

The second, where ODF related RDF vocabulary is being used and which 
will be incorporated into the ODF 1.2 draft.
The second document would reference to first and is quite identical to 
our current metadata proposal and just require minor changes.

BTW a similar inheritance structure was recently used by the W3C 
Compound Document Formats specification (i.e. 
http://www.w3.org/TR/WICD/#related).


Changes to be done on our existing proposal are only namespace related.
We would have differentiate for the metadata manifest the existing 
"odf:" prefixed RDF vocabulary into two vocabularies.
One representing the vocabularies necessary for all packages (e.g. 
prefixed by "pkg:") and a second for the ODF relevant part (still 
prefixed odf:).

As well the namespace of in content metadata would need adoption to be 
reused in a unique way elsewhere.
This is necessary for upcoming RDF package parser to identify package 
metadata in a consistent way even in packages from non ODF applications.

Suggested changes in detail:

1) In content metadata namespace change:
http://docs.oasis-open.org/opendocument/meta#
to
http://docs.oasis-open.org/package/meta#


2) Metadata manifest namespace change:
Changing the namespace of basically the complete odf: prefixed RDF 
vocabulary from
http://docs.oasis-open.org/opendocument/meta/package#
to
http://docs.oasis-open.org/package/meta/manifest#

But still remaining the odf: namespace, which would be slightly changed 
accordingly from
http://docs.oasis-open.org/opendocument/meta/package#
to
http://docs.oasis-open.org/opendocument/meta/manifest#


With the exception of the ODF related elements, which are:

odf:ContentFile - the OpenDocument content.xml
odf:StylesFile - the OpenDocument styles.xml
odf:Element - an OpenDocument XML element

We should introduce for the package an
xml:Element for XML elements, from which odf:Element is a subclass.
As an xml element has no namespace per se, I would suggest 
"http://www.w3.org/TR/REC-xml#Element";

Finally if it is anyhow conformable with RDF, I would suggest a generic 
approach to identify each kind of ODF element by an rdf:type similar to 
its IRI given by namespace and local name.
For consistency reasons of RDF, I would add two minor adoptions before 
reusing the IRI. First insert the delimiter '#' between namespace and 
localname if not existent and second change the first letter of the 
local name according to RDF classes to a capital letter.

For example, some table element in the document could be identified in 
the metadata manifest according from the IRI resulting from table:table.
The RDF class for table:table would be 
"urn:oasis:names:tc:opendocument:xmlns:table:1.0#Table" after the 
adoptions instead of the original 
"urn:oasis:names:tc:opendocument:xmlns:table:1.0table".

<odf:Element rdf:about="uri:someIRI" idref="someID">
    <rdf:type 
rdf:resource="urn:oasis:names:tc:opendocument:xmlns:table:1.0#Table"/>
</odf:Element>

Could be written shortly as
<table:Table rdf:about="uri:someIRI" idref="someID" />

The subclassing of odf:Element from all existing ODF namespaces 
declaring OpenDocument elements would be done in the ODF related draft.

That's seems to be all from the technical stand-point.
What you think?
Svante


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