[CL] OWL -> CL
phayes at ihmc.us
Mon Oct 4 22:23:42 CDT 2010
On Oct 4, 2010, at 3:22 PM, Fabian Neuhaus wrote:
> There is still some stuff which I need to clean up and I did not axiomatize the HasKey primitive yet. However, I won't have time to work on the ontology in the next days, so here it is
> Again, this is a first draft. Also, I am not an expert on OWL or RDF, so I might have gotten some of the lingua wrong.
> Here are two observations:
> (i) CLIFs convention for comments stinks! I understand the theoretical concerns, but there is no way in hell I write (cl:comment " ") each time I want to write a comment.
You are not the first to make this observation. We will incorporate a more conventional commenting syntax in the next version.
> The document above can be turned into a CL compliant document by removing all lines that starts with two backslashes.
> (ii) It was easy to axiomatize the OWL part that is concerned with objects. The hard part was everything that had to do with datavalues and datamaps; and I still feel that what I came up with is only a weak solution.
> I agree with John's point below, but I think it does not only apply to numbers but to all kinds of data values. The OWL guys spend obviously much time on dealing with these. In contrast CL is not well-equiped to handle data values and that's why the translation was difficult. I think we should work on it for the next revision of the CL standard.
Do you mean datatypes? I agree that datatyping and literals should be incorporated (sensibly) into the next version of CLIF. I am sure this can be done in an elegant way within the current CL semantic framework.
> -----Ursprüngliche Nachricht-----
> Von: "John F. Sowa" <sowa at bestweb.net>
> Gesendet: Oct 4, 2010 8:32:18 PM
> An: cl at philebus.tamu.edu
> Betreff: Re: [CL] OWL -> CL
>> On 10/4/2010 11:43 AM, Pat Hayes wrote:
>>> The problem being the need for numerical quantifiers, right?
>>> (That last point is interesting, and suggests something I don't
>>> yet know about IKL:-) Maybe we should think about adding
>>> numerical quantifiers in a new version of CLIF, but it takes
>>> it beyond classical FO, of course. CL has an unusual tension
>>> here between its self-imposed charter of being an umbrella
>>> for classical FO, and being actually useful as a kind of
>>> universal logic-style notation that can represent all the
>>> content needed by things like OWL. Maybe we should discuss
>>> this topic more generally.
>> This issue and several related issues have come up many times before.
>> Not having sets, numbers, and sequences in at least an optional annex
>> to the CL standard has caused many complaints that CL is inadequate
>> for practical applications.
>> I suggest that we adopt the same (or similar) approach used in
>> the Z standard:
>> 1. Include a normative, but optional mathematical toolkit
>> as an annex.
>> 2. In fact the toolkit could be identical to Annex B of Z
>> but translated to CLIF and/or one or more other dialects.
>> 3. Since Z is already an ISO standard and the toolkit is a
>> normative annex to it, there should be little or no objection
>> to including a translation of it for the CL standard.
>> 4. The total length of Annex B is only 16 pages, and it could be
>> translated to CL in parallel with any other work that is being
>> done -- provided that somebody would volunteer to do it.
>> See below for the opening section of Annex B of the Z standard.
>> B.1 Introduction
>> The mathematical toolkit is an optional extension to the compulsory
>> Z core language. It comprises a hierarchy of related sections, each
>> defining operators that are widely used in common application domains.
>> [A diagram that shows set_toolkit, relation_toolkit, function_toolkit,
>> number_toolkit, sequence_toolkit, and standard_toolkit]
>> Figure B.1 Parent relation between sections of the mathematical toolkit
>> The division of the mathematical toolkit into separate sections allows
>> use of certain subsets of the toolkit rather than its entirety. For
>> example, if sequences are not used in a particular specification, then
>> using function toolkit and number toolkit as parents avoids bringing
>> the notation of sequence toolkit into scope. Notations that are not
>> reused can be given different definitions. Section standard toolkit
>> is an implicit parent of an anonymous specication.
>> CL mailing list
>> CL at philebus.tamu.edu
> CL mailing list
> CL at philebus.tamu.edu
IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 mobile
More information about the CL