[OASIS Issue Tracker] Commented: (OFFICE-3475) not place to put RDFin flat ODF document

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/OFFICE-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22415#action_22415 ] 

Dennis Hamilton commented on OFFICE-3475:
-----------------------------------------

Thanks for your comment, Rob.  I have been thinking about this a great deal over the past months, but it wasn't until Jos pointed out the <office:document> case that the coin dropped.  He raises an important opportunity and I think it is far more direct than attempting to somehow drag manifest.rdf and related RDF/XML package components into the <office:document> structure.

Here's my analysis.

IMPORTANT: My suggestion applies to the <office:meta> element in an <office:document> in a free-standing XML document, in a meta.xml in a package, and in an <office:document> embedded in a package.  The game is literally the same when there is no referencing from the <rdf:RDF> to elements in the ODF document that are not within the <office:meta>.  (When the <office:meta> is in a meta.xml document part, the form of references into other parts are necessarily different, although the package rules for IRI references might still be available.)

The package model is not easily preservable by stitching or exploding parts .  While <office:document> can carry the same abstract document structure, the mapping between <office:document> and an equivalent structure in a package is not straightforward.  In particular, the <office:document> is more coherent.

EXAMPLES: Cross-references via IDREF and  IRI internal to the <office:document> must be modified if the target will be in a different part in the equivalent package.   Likewise, the scope of uniqueness of ID attribute values is quite different in the (file containing the) <office:document> than when the structural components are exploded into separate package files.

I think this is significant for RDF/XML which is all about URI references.  The ontologies that are defined for ODF are usable in any RDF anywhere of course, and they can be used in the <rdf:RDF> elements that I suggest.  However they don't *have* to be used for as much and they *can't* be used in the same way as they would be used in a manifest.rdf and in external in-/out-package XML parts because the package components that those files must refer to don't even exist in the <office:document> -- there are no targest for file components -- and needing to refer to an element in the same XML Document is trivial so long as the element has an ID attribute or XPath is used in the RDF.

Extraction of the <rdf:RDF> from <office:meta> does require that relative references into portions of the <office:document> be changed into absolute references, a routine problem for extracted metadata.  That is a known and solved problem for embedded <rdf:RDF>, assuming one comes up with a base URI for the references which will now be back into the <office:document> XML Document from external RDF.  Doing this for packages is problematic, of course, because inward references to elements in parts of packages are not ordinary and the OWL doesn't help us get to an absolute URI from outside of the package, as far as I can tell.

In these ways, we should not consider that <office:document> is some flat version of a package that is simply not in a Zip.  It is too different for that.

Finally, I notice that the RDF/XML specification is difficult and requires considerable analysis to use it well (though there are tools and examples, e.g., simply embedding a Creative Commons license into <office:meta>).

However, we expect RDF/XML for external in-package RDF material already, so that problem is already to be faced by anyone who wants to produce and consume such RDF.  (Conformant Consumers may freely ignore the RDF either way.)  One advantage of allowing <rdf:RDF> in <office:meta> is that it allows simple cases for simple situations, such as adding a Creative Commons license, introducing new metadata of a simple, static nature, and using xml:lang and other provisions that are part of RDF/XML.  This provides a means for providing metadata annotations that do not require anything elaborate.  They can also be more-easily maintained in relative synchronization with other elements of the same XML document (to the extent that referential integrity, if even needed, is more-easily dealt with within a single XML document).

Provision for embedded RDF/XML in this limited way is also immediately usable and of great benefit for simple cases.  This is in contrast with the more heavyweight manifest.rdf, especially considering that we seem reluctant to provide any information at all on what makes manifest.rdf different than any arbitrary RDF/XML file injected into the package and any RDF/XML file anywhere that happens to rely on the two OWL ontologies that we are specifying.

> not place to put RDF in flat ODF document
> -----------------------------------------
>
>                 Key: OFFICE-3475
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3475
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Metadata
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Jos van den Oever
>            Assignee: Patrick Durusau
>
> The metadata can be stored in the ZIP storage of ODF, but there is no equivalent place in the flat file format.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira