Re: [office] Single ODF 1.2 metadata proposal

[Svante Schubert <Svante.Schubert@Sun.COM>]

Hello Dennis,

thank you very much for your valuable feed-back.
Please find my answers below:

Dennis E. Hamilton wrote:
> Svante,
>
> Because this proposal is on the December 15 agenda, I wanted to be more
> conversant with it than I am.  I do have some preliminary and superficial
> comments/questions:
>
> 1. My note on xml:id was inspired by wanting to offer a simplified way to
> handle the metadata proposal and leave open the prospect of being able to
> use URIs for other elements without having to be explicit in the schemas.
> This sketch was intended to simplify the work in the metadata proposal: 
> http://lists.oasis-open.org/archives/office/200812/msg00126.html
>   
Our intention was to add xml:id only on the ODF elements often used in 
metadata scenarios to keep the effort for ODF application in our initial 
specification of RDF metadata in Office documents as low as possible.
> 2. Should there be a metadata:version on the root element of a metadata rdf
> file?  On the manifest.rdf file (so the root might not be rdf, but have the
> rdf as an element?  Or could there simply be any kind of rdf in metadata RDF
> files, about anything in their about: attributes?
>   
We simply reuse the existing W3C RDF standard and provide an OWL 
vocabulary to describe ODF elements.
Our intention was to stick as close as possible with the RDF standard.
A version property is already usable as user defined vocabulary and 
could be set in the future as default to the start version "1.0".
Therefore a version property is more important in the upcoming version.
> 3. Is there a way to have this proposal work with a single-file XML document
> having <office:document> root element?  Does the embedded-within-the
> document case handle that.  That isn't clear to me.  It appears that the in
> Content Metadata is constrained to appear on particular elements and not sit
> over the entire document the way a separate metadata RDF file would appear
> to be. 
>   
Of course it is possible to move every single files of a package into a 
flat file, embedding all RDF/XML files into a single XML file.
AFAIK there is no generic way specified to move every file of a package 
into a single stream.
For instance dependent on the mime type every user data (e.g. RDF/XML) 
could be plain or BASE64 encoded embedded into a flat XML file.
Personally I do not like the flat XML file. The only usage of flat XML 
files I am aware of - the XSLT handling in OOo - I am about to adopt to 
work on the ODF package instead of the flat XML file. (Neglecting 
performance/memory annoying BASE64 encoding for images)
> 4. Wouldn't the individual RDF metadata files in an ODF package also appear
> in the ODF manifest.xml file?  Would not their MIME types be expressed there
> in any case?
>   
Yes, every file of the package is in the manifest.xml, together with its 
MIME type (ie. "application/rdf+xml").
Nevertheless only in the manifest.rdf the association of an RDF/XML file 
to an RDF types (which is necessary so that interested plug-ins etc. can 
find them) is being stated.
Also, there is one manifest.xml per package, but one manifest.rdf per 
document (in case of embedded documents).
> 5. This statement on the bottom of page 6 is unclear for me:
>
> "Every OpenDocument XML element with an xml:id attribute is itself a OWL
> class identified by the concatenation of it's XML Namespace and it's XML
> local name. These classes are subclasses of odf:Element."
>
> So is such a specific element an OWL class or an OWL class instance?  (I may
> be confusing OWL class with other kinds of classes.)  Also, would the
> instance be identified {namespace}:local-name#id-value (and would not
> {namespace}:local-name be the class? 
>   
In RDF a resource might be described by one or more OWL classes.
For instance there be the resource called 'Wine' described in RDF.
It could be of type 'ex:Food' (in detail 
'http://myexampe.org/example#Food'), ex:Beverage, ex:Bordeaux.
In the same way, we are describing our ODF resources to be of 
odf:Element and more explicitly when it is a table as of class 
'table:table'.
The basic idea, we resue the ODF element namespace to describe the ODF 
element in the RDF context instead of inventing arbitrary new ones.
> 6. I have more questions about context for situations such as in (5), but
> don't know enough to ask them properly.
>   
I could offer you to call me directly and try to explain me your 
problems, perhaps we can elaborate to define your question in a dialog 
before asking them in public on the list.
> 7. Regarding section 1.2.2, I don't see anywhere that an xmlns:xhtml
> namespace declaration has been made, and the usage in 1.2.3 needs support
> with an authoritative namespace declaration also.  (Oh, I see the tabulation
> in 1.5.5.  They really piled those into an old namespace?  Big sigh.)
>   
We can be quite happy that we have now a recommendation for RDFa, the 
namespace leads to the definition of RDFa.
I see no problem in using an 'old' namespace and in any case, if there 
is a problem, it's not ours ;-)
> 8. Section 1.4 carries the statement that "All OpenDocument elements of the
> meta.xml should be mapped to RDF." that seems to be quoted below.  I
> understand this is for a processor that is creating an external RDF/XML
> corresponding to the meta.xml.  
Not only creating an external file for non ODF application, but as well 
for ODF applications the information of the meta.xml should be 
accessible via RDF.
For instance if someone is making a query on the RDF statements of a 
document the meta.xml informations should be accessible via RDF.
> Yet I suspect that the extracted metadata
> files within the package would be using package-relative URIs and they would
> not want to be tied to the external name of an instance of the file in a
> particular (potentially ephemeral) location.  Is there something
> contradictory about this?  It would seem that the document needs an IRI but
> I am thinking maybe it is something found inside the document (a URN
> perhaps?) and not tied to an ephemeral resource location.
>   
As all 'inside' references to resources within the package are relative 
URLs, the resolution of the relative URLs is being done from 'outside'.
For instance a metadata crowler gathering metadata of ODF documents, 
would resolve the relative URLs.
The ephemeral resource location is a problem of the crawler, but as we 
see by the success of search engine companies, not a fundamental problem.
Still a metadata application has the opportunity to add an URN to the 
document by RDF techniques (e.g. using OWL property owl:sameas).

Tim Berners Lee emphasized in Cannes that RDF resources in the web 
(where ODF should be a part of) should be accessible via URLs.
The Semantic Web needs URLs to become a web.
> 9. I would hope that there is another way to accomplish what section 1.5.1
> attempts.  Maybe just a general rule that an instance of an element that can
> be a viewed as an RDF object must have an xml:id and that's that?  (I was
> hoping my suggestion about xml:id would facilitate that.)  Also, I think we
> should require preservation of xml:id on elements so long as the element
> itself is preserved.  [I'm wary of the referential integrity condition
> because we don't know if it is (semantically) the same element any longer,
> if the xml:id is change.]
>
>   
Only ODF elements with an xml:id can be described as RDF resources, the 
default addition of xml:id seems again like a burden to ODF applications 
to me.
The general thumb rule should be: "Let the user only pay for what he is 
using".

The xml:id feature is nevertheless independent of the metadata feature 
and might be used by other ODF features.
(For instance in the future to refer to the elements by an URL like 
using ODF fragment identifier, that I will suggest after ODF 1.2.).

The xml:id is similar to an API of a program. It is a way of public 
access of inner document resources and should therefore not being 
altered if not explicitly desired by an user.
> 10. I am wondering if life could be made much simpler simply by having a
> common-element-attlist for all ODF elements and allow, in that an optional
> xml:id attribute and an optional common-in-content-meta-attlist and let the
> chips fall where they may?
>   
As stated earlier: I suggest to keep the effort for ODF applications low 
in the first place.

Thank you very much for your feed-back, Dennis!
Svante
>  - Dennis
>
> -----Original Message-----
> From: Svante.Schubert@Sun.COM [mailto:Svante.Schubert@Sun.COM] 
> http://lists.oasis-open.org/archives/office/200812/msg00108.html
> Sent: Friday, December 12, 2008 08:28
> To: OASIS Office
> Cc: Michael Stahl
> Subject: Re: [office] Single ODF 1.2 metadata proposal
>
> Dear TC members,
>
> from the feedback of my colleagues, I did the following minor fixes to the
> metadata proposal and uploaded it to:
>  
> http://www.oasis-open.org/committees/download.php/30371/08-12-12-ODF-Metadat
> a-Change-Request.odt
>
> 1) As only relative URLs should be used to refer to inner package resources
> within RDF/XML, the OWL properties 'pkg:idref', 'pkg:path' and 'pkg:hasPart'
> (the pkg:hasPart to express the relationship of an xml file and xml element
> with ID) become redundant.
> In addition the wording of the relative URLs for inner package references
> had been improved.
>
> 2) As stated previously GRDDL will extract the RDFa from content.xml and
> styles.xml to RDF/XML and map the OpenDocument XML of the meta.xml to
> RDF/XML via XSLT.
> I was asked to add explicitly in the specification that the common meta.xml
> elements should be mapped to RDF by an ODF application in a defined way:
>
> "All OpenDocument elements of the meta.xml should be mapped to RDF. 
> The algorithm is provided by the OASIS hosted XSL stylesheet. [Editor's
> Note: Add link] "
>
> The stylesheet is an implementation detail, but a mapping from meta.xml to
> RDF could be done as the following:
>
> meta.xml:
> <office:document-meta xmlns:office="....>
>     <office:meta>
>         <meta:print-date>2004-08-20T07:38:27</meta:print-date>
>         <meta:user-defined meta:name="achieved
> at">26.08.2004</meta:user-defined>
>         <meta:user-defined meta:name="working hours">5</meta:user-defined>
>         <meta:document-statistic meta:table-count="5" meta:image-count="3"
> />
>
> RDF (N3):
> <DOCUMENT_IRI> meta:print-date "2004-08-20T07:38:27" . 
> <DOCUMENT_IRI> meta:document-statistic [meta:table-count "5";
> meta:image-count="3"]
> <DOCUMENT_IRI> meta:user-defined [meta:name "working hours"; meta:value "5"]
> . 
> <DOCUMENT_IRI> meta:user-defined [meta:name "working hours"; meta:value
> "26.08.2004"] . 
>
> Where <DOCUMENT_IRI> is the IRI to the document of the meta.xml (document
> root).
> E.g. the <DOCUMENT_IRI> for the meta.xml of the root document of the
> uploaded proposal would be:
>  
> http://www.oasis-open.org/committees/download.php/30371/08-12-12-ODF-Metadat
> a-Change-Request.odt/
>
> Regards,
> Svante
>
> [ ... ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>   

-- 
Sun Microsystems GmbH           Svante Schubert
Nagelsweg 55                    Software Engineer
20097 Hamburg                   StarOffice / OpenOffice.org Development
Germany                         Phone: +49(0)40 236 46 500
http://www.sun.com              Svante.Schubert@sun.com

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering