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: Re: [office-metadata] Reuse of metadata proposal for non ODF applications



On Jun 24, 2007, at 12:15 PM, Svante Schubert wrote:

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

Well, but I think we need to the TC to say they want this before we do 
anything about it.

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

I get a 404 on the root package URI, so we'd need to address that. Who 
would control that URI? The ODF TC?

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

??? Why the "manifest" at the end? Isn't that redundant?

> 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";

Hmm ... I have a feeling this might be a little dicey. Not sure you can 
really do this.

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

I don't know, this feels problematic too. We're going to reuse existing 
IRIs, except not really? Those existing IRIs are not resolvable?

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

I'm curious if Elias finds the time to comment on this, but this just 
seems wrong to me. It's basically a hack to create more human readable 
and namespace-prefixable IRIs by getting around the fact that the 
original namespace IRIs for ODF 1.1 weren't designed with RDF in mind.

Bruce



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