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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: RDF Metadata Proposal: Association of OWL Classes and ID'd Elements

1. In section 18.1278 xml:id in OpenDocument-v1.2-draft7-13.odt, there are the following statement:

  [1.1 existing text[
The xml:id attribute is standardized by the W3C [XML-ID] and gives an element an unique identification in its XML file. It is designed to work as an anchor to create references upon its element.

All implementations should preserve any xml:id attribute and its value when present on any of the elements listed in [TODO]. If an applications changes an xml:id attribute value, it should update any associated bindings in the metadata manifest to maintain referential integrity.

  1.2 The citation is to [XML-ID] Jonathan Marsh, Daniel Veillard, Norman Walsh, xml:id, http://www.w3.org/TR/xml-id, W3C, 2003. That is not the proper citation of the actual (and only, at this time) W3C Recommendation for xml:id.  

  1.3 An appropriate citation is [XML-ID] Jonathan Marsh, Daniel Veillard, Norman Walsh (eds).  xml:id Version 1.0, W3C Recommendation 9 September 2005, available at <http://www.w3.org/TR/2005/REC-xml-id-20050909/>.  All of my comments on the use of xml:id and any other attributes of type ID, attributes of type IDREF and IDREFs, etc., are based on this specification.

  1.4 I also have my doubts about the wording concerning preservation of referential integrity.  I am not discussing that here.

2. In section odf:Element in OpenDocument-v1.2-draft7-13.odt, there is the following statement:

   [2.1 existing text[
Every XML element in an OpenDocument package (or single file) with an xml:id attribute is itself an OWL class identified by the concatenation of it's XML Namespace and it's XML local name. These classes are subclasses of odf:Element.

   2.2 By my rough count, there are currently over 75 elements that can have xml:id attributes according to OpenDocument-v1.2-draft7-13.odt.  (See the list at the end of this note.)

   2.3 SUGGESTION: I think that the wording in section might be more appropriate if restated as follows:
For purposes of the RDF metadata, every XML element in an OpenDocument package instance that has an xml:id attribute '''can''' be interpreted to represent a member of an OWL class identified by concatenation of the element's XML Namespace and the element's local name.  These classes are subclasses of odf:Element.  RDF metadata invokes that interpretation by referring to the element in a manner where the odf:Element subclass interpretation is intended.

Example: In a content.xml package subfile containing an element tag


   The OWL class is identified {urn:oasis:names:tc:opendocument:xmlns:table:1.0}table-cell
   (in a common notation for concatenating namespace identifiers and local names).  The 
   instance of the member of that OWL class is identified by a URI path that ends at resource

   2.4 IS THIS CLOSE TO RIGHT?  I have no idea -- it is just my effort at making sense of the original statement making significance of the ID associated with the element.  I can imagine that it might be more apt to say that "The supported classes are defined as subclasses of odf:Element."

   2.5 It is my understanding that [XML-ID] (and [XML 1.0]) provides that any attribute of type ID be usable as a fragment identifier so it might be appropriate to restate the proposal in (2.3) to refer to elements with an attribute of type ID rather than only xml:id attributes.  The only examples in RDFa where an ID is provided do not use xml:id, in fact. 

   2.6 I can understand the preference for xml:id to ensure that there is no ambiguity to be dealt with in the resource portion of the URI.  However, so long as no element may have more than one attribute of type ID (an XML 1.0 validity rule for attributes of ID type), there is no problem.  I suppose it is useful for purposes of metadata creation and processing that all URI fragment IDs will refer to xml:id attributes as a convenience in processing without having to pay much attention to the schema for the element and the types of other attributes that might be present.  I think, technically, this depends on being able to count on no other attribute on the element having a value of type ID before adding an xml:id attribute to the element.

3. I cannot find any justification for tying everything to an OWL ontology at all.  I can find very little in the current RDFa specification that says much about URI fragment identifiers or fragment references.  So I cannot tell from the material in the proposals what the use of xml:id by the RDF metadata actually is and how it is relevant to inventing OWL classes around XML elements of ODF.  The main applications of RDF are to describe what an element is about, not what its type is.

[I'm a little frustrated at how much searching I have done with little result.  This frustration is probably showing through.  I apologize for that but it is getting late and I want to put some sort of flag on the play, so I can get on to reviewing other proposal content. -- dh:]

   3.1 Based on my ignorance so far, here are other ways I am baffled about RDFa (although I understand that we are talking about using attributes as a way of weaving RDF into the document structure itself) and how little of it seems to actually apply in a profiling for use with ODF.  

   3.2 I do not know what are the authoritative references that are to be the basis for the use of RDF, OWL, and RDFa for metadata under the ODF 1.2 specification.  I think they have not been added to the ODF 1.2 draft yet.  It makes it hard to cross check against something authoritative.  

   3.3 Most of the really-useful, low-hanging fruit uses of RDF[a] to markup a document in-line don't require constraining with an OWL ontology either.  There's not one use of OWL in the RDFa specification.  I'm beginning to worry what problem this is all meant to be the solution to.  

   3.4 The only authoritative reference I find for RDFa is [RDFa] Ben Adida, Mark Birbeck, Shane McCarron, Steve Pemberton (eds.).  RDFa in XHTML: Syntax and Processing, W3C Recommendation 14 October 2008, available at <http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/>.  This specification has some strict requirements for use in conjunction with XHTML.  For example, it specifies the root element of any XML document that contains RDFa markup.  It relies on XHTML elements that have no counterparts in the XML grammar for ODF documents.  It has examples that have no earthly correspondence to XML ODF.  What is our profile of this specification with respect to how RDFa is employed in conjunction with ODF elements?    

   3.5 The main case of fragment identifiers used in subject and object position is as in [RDFa]  Is this what we have in mind?  It is unfortunate that we have no <odf:base> element (attribute, preferably, because of foreign element rules) to drop in wherever we want.  Likewise, I do not know how has a counterpart in the ODF metadata specification.  The first example in is also a case where fragment references are used.  (So the assertion that relative URIs are verboten in RDF is not quite accurate.)

   3.6 I happen to think that the kind of metadata markup provided for in RDFa is very cool.  But, as far as I can tell, none of this is being used or being allowed as part of the ODF RDF Metadata proposal.  Since it is not really being used, why is it being featured as the heart of the RDF Metadata approach for ODF?  What's the story?

   3.7 Finally, with regard to the Metadata Manifest Example in the January 2008 ODF Metadata Examples document, the observation about relative URIs is misleading.  The rule is that there cannot be a relative URI without having a base that grounds the URI.  I just ran across an example while scanning RDF specifications which did just that to have a document be location independent -- that is, its metadata was made dependent on the document file but not on the location of the (particular identical copy of the same) document file, by using a fixed base URI for its "absolute" identity (like those urn:uuid values or better yet, some http://.../224ab023-77b8-4396-a75a-8cecd85b81e3/ that is uniquely generated for the specific document but might or might not be dereferenceable.  Very Semantic Webish.  I believe this is the kind of thing someone interested in adding RDF metadata is looking for.

 - Dennis


* indicates that this use of xml:id is (also) part of the deprecation of an existing ID attribute with a different name.

In OpenDocument-v1.2-draft7-13.odt, we have the following occurrences of xml:id on elements.  "*" after the name indicates that the introduction of xml:id is (also) part of deprecating an attribute of ID type that has a different name than xml:id.

<text:h> *
<text:p> *
<text:changed-region> *
<draw:page> *
<draw:rect> *
<draw:line> *
<draw:polyline> *
<draw:polygon> *
<draw:regular-polygon> *
<draw:path> *
<draw:circle> *
<draw:ellipse> *
<draw:connector> *
<draw:caption> *
<draw:measure> *
<draw:control> *
<draw:page-thumbnail> *
<draw:g> *
<draw:glue-point> *
<draw:frame> *
<draw:text-box> * 
<dr3d:scene> *
<dr3d:cube> *
<dr3d:sphere> *
<dr3d:extrude> *
<dr3d:rotate> *
<draw:custom-shape> *
<form:text> *
<form:text-area> * <form:textarea> ? *
<form:password> *
<form:file> *
<form:formatted-text> *
<form:number> *
<form:date> *
<form:time> *
<form:fixed-text> *
<form:combobox> *
<form:listbox> *
<form:button> *
<form:image> *
<form:checkbox> * 
<form:radio> *
<form:frame> *
<form:image-frame> *
<form:hidden> *
<form:grid> *
<form:value-range> *
<form:generic-control> *
<office:annotation> *
<anim:par> *
<anim:seq> *
<anim:interate> *
<anim:audio> *
<anim:command> *

Dennis E. Hamilton
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 

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