Warning:
This wiki has been archived and is now read-only.

LC Responses/ALR1

From OWL
(Redirected from LC Responses/ATST1)
Jump to: navigation, search

To: Alan Rector <rector@CS.MAN.AC.UK>
CC: public-owl-comments@w3.org
Subject: Re: [LC response] To Alan Rector

Dear Alan,

We sent a response
     <http://lists.w3.org/Archives/Public/public-owl-comments/2009Jan/0063.html>
to your comment on our OWL 2 specifications, and in our response we asked if you are satisfied. We have not yet heard back from you. If we do not hear from you soon, we will proceed on the assumption you are satisfied with our response.

Regards,
Bijan Parsia
on behalf of the W3C OWL Working Group


CUT AND PASTE THE BODY OF THE MESSAGE (I.E. FROM "Dear" TO "Group") INTO THE BODY OF AN EMAIL MESSAGE. SET THE To:, CC:, AND Subject: LINES ACCORDINGLY.

PLEASE TRY TO REPLY IN A WAY THAT WILL ALLOW THREADING TO WORK APPROPRIATELY, I.E., SO THAT YOUR REPLY CONTINUES THE THREAD STARTED BY THE ORIGINAL COMMENT EMAIL


To: Alan Rector <rector@CS.MAN.AC.UK>
CC: public-owl-comments@w3.org
Subject: [LC response] To Alan Rector

Dear Alan,

Thank you for your comment
     <http://lists.w3.org/Archives/Public/public-owl-comments/2008Dec/0000.html>
on the OWL 2 Web Ontology Language last call drafts.

The working group has decided to make no change to OWL 2 in response to your comment. While we appreciate the use cases raised in your comment, we found that the specification and technical difficulties of adding such a feature at this time outweigh the benefits it would bring, esp. given the existence of various workarounds. For example,

  • One could embed class expressions in literals, i.e., xsd:string or XMLLiteral. While you point out that "strings rust", one could introduce a named subtype of xsd:string that would allow tools, such as Protege 4, to syntax check the expressions.
  • One could introduce a named class for the expression. To avoid cluttering the class hierarchy with these classes, one could either annotate the axioms, or use a distinguished naming scheme, or make them subclasses of a certain class.
  • In OWL Full, this is available in certain forms. So one could use OWL Full to guide an extension.

The main issue with such workarounds is, of course, interoperability. However, we do feel confident that reasonable interoperability could be accomplished by your publishing details of the annotations (or naming scheme, or subtype) and having your popular tools support it.

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,
Bijan Parsia
on behalf of the W3C OWL Working Group


CUT AND PASTE THE BODY OF THE MESSAGE (I.E. FROM "Dear" TO "Group") INTO THE BODY OF AN EMAIL MESSAGE. SET THE To:, CC:, AND Subject: LINES ACCORDINGLY.

PLEASE TRY TO REPLY IN A WAY THAT WILL ALLOW THREADING TO WORK APPROPRIATELY, I.E., SO THAT YOUR REPLY CONTINUES THE THREAD STARTED BY THE ORIGINAL COMMENT EMAIL


Looking over the spec for OWL annotations again in the Syntax Spec - thanks for all the work - I realise that we have a number of use- cases for having OWL expressions rather than just IRIs as the values of annotations.

Once suggested, several others have chimed in with other use cases. I know it is late in the day, but ...

Briefly, some use cases are:

  • Mapping applications between ontologies where full logical equivalence/subsumption cannot be, or has not yet been, achieved. When mapping to thesauri and other artefacts that are explicitly linguistic or associational rather than logical, this is very common.
  • Stored queries & test expressions & related maintenance information.
  • Various information maintained for handling collaboration, e.g. alternative definitions of the "same" entity under consideration.
  • Cross reference links within the ontology where we don't want to create a named class explicitly to clutter the hierarchy
  • To be able to retain as annotations axioms whose proper inclusion kills classifiers. Keeping them with the original ontology for integrity is important, even if they have to be censored

In each of these cases we want to

a) have the expression be a syntactically legal (but not necessarily satisfiable) OWL expression using the identifiers/names in the ontology;

b) track identifier/name changes within the ontology so that the referential integrity of the expression is conserved even through updates, version changes etc. Strings rapidly rust. For the same reason that we need entities (or IRs in the ontology) in annotations, we need expressions made up of those those IRIs are treated in the same way - essentially "anonymous class value")

Peter: My suggestion is to use strings that are syntactic representations of the complex class expressions. This would not require any change to the spec.

Ian: Of course Alan foresaw and ruled out this suggestion in his email. He said that "expressions should be syntactically legal" and that "strings rapidly rust" -- although it seems to me that what he says about tracking changes etc. is equally true of regular syntax. Although I prefer Peter's suggestion, an alternative that we might also suggest is to use named classes, i.e., to add an axiom of the form EquivalentClasses(ex:A_New_Name ex:The_Concept_Expression) and then use the class ex:A_New_Name in the annotation. The likely objection to this would be that the class hierarchy gets cluttered with new names.

Alan: More change than above, but manageable: Extend the structural syntax by allowing class expressions to be quoted. Serialization can still be as string (in the same syntax as the document that includes the assertion) or could be extending serialization, e.g. in RDF using something like:

Tools that worked at the level of the structural syntax would then have the quoted and unquoted

See this thread

Retrieved from "https://www.w3.org/2007/OWL/wiki/index.php?title=LC_Responses/ALR1&oldid=18804"