Difference between revisions of "LC Responses/JR8-2"

From OWL
Jump to: navigation, search
 
Line 37: Line 37:
 
First of all, as you yourself noted, developing such an XML encoding is not in the charter of the OWL 2 Working Group. Taking into account the fact that there is no group at the moment whose charter could reasonably include such a development, that means that, in the meantime, the needs of a distinct community would not be fulfilled for a long time.
 
First of all, as you yourself noted, developing such an XML encoding is not in the charter of the OWL 2 Working Group. Taking into account the fact that there is no group at the moment whose charter could reasonably include such a development, that means that, in the meantime, the needs of a distinct community would not be fulfilled for a long time.
  
There is, however, a further issue to consider. Let us suppose that a regular XML encoding, closely reflecting RDF triples, were used (something like TriX[1], for example). That would mean that OWL construct would have to be encoded in, essentially, an XML transliteration of N-triples. Though this would be well defined, it would still be complicated to manage the resulting XML content through, say, XPath, and almost impossible to define an XML schema that could be used by a schema aware editor. This is simply due to the fact that the triple representation of OWL constructs are, by their very nature, fairly complex (think of the representation of class intersections using RDF lists). One could of course imagine a slightly more complex XML encoding of RDF, but it is unclear at the moment what that would be. In other words, relying on a generic XML format for RDF may not satisfiy the requirements end users have for such a serialization of OWL due to its inherent complexity.  
+
There is, however, a further issue to consider. Let us suppose that a regular XML encoding, closely reflecting RDF triples, was used (something like TriX[1], for example). That would mean that OWL construct would have to be encoded in, essentially, an XML transliteration of N-triples. Though this would be well defined, it would still be complicated to manage the resulting XML content through, say, XPath, and almost impossible to define an XML schema that could be used by a schema aware editor. This is simply due to the fact that the triple representation of OWL constructs are, by their very nature, fairly complex (think of the representation of class intersections using RDF lists). One could of course imagine a slightly more complex XML encoding of RDF, but it is unclear at the moment what that would be. In other words, relying on a generic XML format for RDF may not satisfiy the requirements end users have for such a serialization of OWL due to its inherent complexity.  
  
 
Note that having specialized formats for 'sub'-languages on the Semantic Web is not specific to OWL. A typical example might be the XML encoding of Resource Descriptions in POWDER[2], which provides an XML syntax for end users but also defines a formal transformation of that XML encoding into OWL. As long as these languages clearly map on a common and required exchange format (which is the case for OWL 2), they can be valuable in serving various specialized communities without damaging interoperability.
 
Note that having specialized formats for 'sub'-languages on the Semantic Web is not specific to OWL. A typical example might be the XML encoding of Resource Descriptions in POWDER[2], which provides an XML syntax for end users but also defines a formal transformation of that XML encoding into OWL. As long as these languages clearly map on a common and required exchange format (which is the case for OWL 2), they can be valuable in serving various specialized communities without damaging interoperability.

Latest revision as of 10:14, 11 March 2009

I can understand the problem of XML tools, but I think this must be

solved by the/an RDF/XML WG, and *not* by the OWL WG. If we take a look at the diagram in http://www.w3.org/2007/OWL/wiki/Document_Overview, we see 3 OWL syntaxes and 2 RDF syntaxes! In addition we see 2 models: OWL2/Structure and OWL2/RDF. As a tool-developer, this is getting `babylonial proportions' ... Soon we will see applications like ImageMagic (bitmaps) or gpsbabel (GPS data) for the semantic web.

I'm totally happy to whatever and syntax and model tools and comunities want to use internally, but why must all these alternatives be described as part of the standard? It is ok to use the abstract/functional syntax to simplify describing the semantics of OWL, but please do not propose it as a concrete syntax. It can (and does, see for example Thea, http://www.semanticweb.gr/TheaOWLLib/) play a role in defining an OWL API for a programming language. This is totally fine.

I fear that presenting the SW using so many practically isomorphic languages harms the initiative.

(not the complete mail, it would be too long to reproduce here, see the original mail

See also discussion thread on the list.


Dear Jan,

This is an answer to your message

 http://lists.w3.org/Archives/Public/public-owl-comments/2009Mar/0000.html

giving further comments on the OWL 2 Web Ontology Language last call drafts.

You are correct that a completely XML "friendly" encoding of RDF could indeed be used to encode OWL 2 ontologies and could, therefore, be used as part of a more complete XML workflow. There are, however, several issues that must be considered.

First of all, as you yourself noted, developing such an XML encoding is not in the charter of the OWL 2 Working Group. Taking into account the fact that there is no group at the moment whose charter could reasonably include such a development, that means that, in the meantime, the needs of a distinct community would not be fulfilled for a long time.

There is, however, a further issue to consider. Let us suppose that a regular XML encoding, closely reflecting RDF triples, was used (something like TriX[1], for example). That would mean that OWL construct would have to be encoded in, essentially, an XML transliteration of N-triples. Though this would be well defined, it would still be complicated to manage the resulting XML content through, say, XPath, and almost impossible to define an XML schema that could be used by a schema aware editor. This is simply due to the fact that the triple representation of OWL constructs are, by their very nature, fairly complex (think of the representation of class intersections using RDF lists). One could of course imagine a slightly more complex XML encoding of RDF, but it is unclear at the moment what that would be. In other words, relying on a generic XML format for RDF may not satisfiy the requirements end users have for such a serialization of OWL due to its inherent complexity.

Note that having specialized formats for 'sub'-languages on the Semantic Web is not specific to OWL. A typical example might be the XML encoding of Resource Descriptions in POWDER[2], which provides an XML syntax for end users but also defines a formal transformation of that XML encoding into OWL. As long as these languages clearly map on a common and required exchange format (which is the case for OWL 2), they can be valuable in serving various specialized communities without damaging interoperability.

Please acknowledge receipt of this email to <mailto:public-owl-comments@w3.org> (replying to this email should suffice). In your acknowledgment please let us know whether or not you are satisfied with the working group's response to your comment.

Regards, Ivan Herman on behalf of the W3C OWL Working Group


[1] http://www.hpl.hp.com/techreports/2004/HPL-2004-56.html [2] http://www.w3.org/TR/powder-primer/