[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] RDF Metadata Proposal: Association of OWL Classes andID'd Elements
Dennis,
Please find some comments in the text.
Dennis E. Hamilton schrieb:
> 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.
> ]]
>
I have dropped the following part from the proposal:
"If an applications changes an xml:id attribute value, it should update
any associated bindings in the metadata manifest to maintain referential
integrity."
The problem is that other RDF/XML files of the package may have as well
reference and even not fixable other resources outside the package might
refer to those xml:ids.
An xml:id is like a public API, once given it should not be changed.
Therefore we drop the latter part of the sentence in the spec.
> 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.
>
I have fixed the year typo of the W3C xml:id specification reference.
> 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.
>
see 1.2
> 1.4 I also have my doubts about the wording concerning preservation of referential integrity. I am not discussing that here.
>
Dropped that wording (see 1.1).
> 2. In section 3.2.2.6 odf:Element in OpenDocument-v1.2-draft7-13.odt, there is the following statement:
>
> [2.1 existing 3.2.2.6 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 3.2.2.6 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.
>
You are right, we might improve the wording here. I would even go a step
further and suggest based on your approach the following:
"In the RDF metadata, every XML element in an OpenDocument package
stream that has a type ID attribute may be described using an OWL class,
which URI is the concatenation of the element's XML Namespace IRI and
the element's local name."
to replace
"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."
> Example: In a content.xml package subfile containing an element tag
>
> <table:table-cell
> xml:id="cellT1A1B732"
> xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0"
> >
>
> 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
> "content.xml#cellT1A1B732"
>
The common notion need some reference. I am only aware of this in an
internal Java context and never found it in RDF files.
> 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."
>
Let me make an example based on yours.
Imagine you want to add metadata to a cell in a ODF document on your
hard disc '/projects/projectA.ods'.
The RDF resource being described might have the URL
file:///projects/projectA.ods/content.xml#cellT1A1B732.
The base URL of the ODF package would be file:///projects/projectA.ods
The RDF statements would be encoded in N3 and RDF/XML in the following
manner:
in N3 like:
@prefix odf: <http://docs.oasis-open.org/ns/office/1.2/meta/odf#> .
@prefix table: <urn:oasis:names:tc:opendocument:xmlns:table:1.0> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
<file:///projects/projectA.ods/content.xml#cellT1A1B732> rdf:type
<odf:Element>, <table:table-cell>
and in RDF/XML like:
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:odf="http://docs.oasis-open.org/ns/office/1.2/meta/odf#";
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0">
<rdf:Description
rdf:about="file:///projects/projectA.ods/content.xml#cellT1A1B732">
<rdf:type rdf:resource="odf:Element"/>
<rdf:type rdf:resource="table:table-cell"/>
</rdf:Description>
</rdf:RDF>
or
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:odf="http://docs.oasis-open.org/ns/office/1.2/meta/odf#";
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0">
<odf:Element
rdf:about="file:///projects/projectA.ods/content.xml#cellT1A1B732">
<rdf:type rdf:resource="table:table-cell"/>
</odf:Element>
</rdf:RDF>
or
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:odf="http://docs.oasis-open.org/ns/office/1.2/meta/odf#";
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0">
<table:table-cell
rdf:about="file:///projects/projectA.ods/content.xml#cellT1A1B732">
<rdf:type rdf:resource="odf:Element"/>
</table:table-cell>
</rdf:RDF>
> 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.
>
I agree on the change of the wording (switching "xml:id" with "type ID").
The xml:id feature is not part of the metadata enhancement proposal of
tomorrow (next Monday) and should be discussed separately.
> 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] 6.1.1.1. 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 6.1.1.2 has a counterpart in the ODF metadata specification. The first example in 6.3.2.1 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?
>
The justification for the usage of OWL to describe the metadata manifest
written in RDF, is the same as for its general usage with RDF, it adds
useful functionality.
OWL allows you to categorize RDF resources (in our case ODF resources).
RDFa had been added to embrace ODF element text content into the RDF
graph without the need of data duplication.
> 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.
>
The Metadata Manifest Example is only informative and not part of the
proposal to be agreed on tomorrow.
The document will be updated most likely by myself after the integration
of the proposal.
Regards,
Svante
>
> - Dennis
>
> LIST OF ODF 1.2 ELEMENTS THAT CAN HAVE xml:id ELEMENTS
>
> * 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:list>
> <text:list-header>
> <text:list-item>
> <text:numbered-paragraph>
> <text:section>
> <text:changed-region> *
> <text:meta>
> <text:bookmark>
> <text:bookmark-start>
> <text:meta-field>
> <text:index-title>
> <text:table-of-content>
> <text:illustration-index>
> <text:table-index>
> <text:object-index>
> <text:user-index>
> <text:alphabetical-index>
> <text:bibliography>
> <table:table>
> <table:table-row>
> <table:table-cell>
> <table:covered-table-cell>
> <table:table-column>
> <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> *
> <draw:a>
> <dr3d:scene> *
> <dr3d:cube> *
> <dr3d:sphere> *
> <dr3d:extrude> *
> <dr3d:rotate> *
> <draw:custom-shape> *
> <presentation:sound>
> <chart:chart>
> <chart:series>
> <chart:data-point>
> <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
>
>
> ---------------------------------------------------------------------
> 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
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]