W3C home > Mailing lists > Public > public-rif-wg@w3.org > February 2007

ACTION 227 done - (was: Re: [RIFRAF] ho to proceed? Part I: Ontologization)

From: Axel Polleres <axel.polleres@urjc.es>
Date: Wed, 21 Feb 2007 10:41:05 +0100
Message-ID: <45DC13B1.4010404@urjc.es>
To: W3C RIF WG <public-rif-wg@w3.org>
http://www.w3.org/2005/rules/wg/track/actions/227

Find some slides explaining my ideas for RIFRAF 
Ontologization/Formalization attached.

Discussion/Feedback/Volunteers to join very welcome!

axel

Axel Polleres wrote:
> Attached you find the latest version of the proposed RIFRAF Base 
> ontology (in OWL and as a protege project file)... more details follow 
> in the next mail.
> 
> axel
> 
> Axel Polleres wrote:
> 
>>
>> Leora Morgenstern wrote:
>>
>>> I agree that to a certain extent the construction of the RIFRAF 
>>> ontology depends on finalizing the core.
>>> I think that an equally important prerequisite --- and one that we 
>>> ought to be doing now ---- is going through the list of RIFRAF 
>>> discriminators  and seeing if we can clear it up and flesh it out as 
>>> much as possible.
>>
>>
>>
>> I see the discriminators more as a way for people to articulate 
>> "features", maybe we should collect/stabilize the issues that we  have 
>> collected so far (for a summary see the other mail:
>> http://lists.w3.org/Archives/Public/public-rif-wg/2007Jan/0106
>> ) and focus to start with a small ontology bottom-up now.
>>
>>> Let me give two examples of the sort of clean-up/fleshing-out that I 
>>> believe is necessary.
>>>
>>> (1) In December, Harold Boley and I discussed some of the 
>>> discriminators in Sections 1 and 2  of the RAF document, Syntactic 
>>> and Syntactic-Entailing-Semantic Discriminators. It appeared from our 
>>> discussion that the distinction between these categories was not 
>>> always clear, and that perhaps these categories should be 
>>> re-organized or restructured.  (Harold, please correct me if I am 
>>> incorrect.)
>>>
>>> In addition, it was not clear why certain syntactic features, but not 
>>> others, were called out in the RAF document. For example,  why 
>>> (Section 1.3) are Monotonic Lloyd-Topor Extensions specifically 
>>> mentioned, as opposed to other types of syntactic sugars?
>>
>>
>>
>>
>> Let me reformulate what I wanted to propose in the original mail:
>>
>>  I did a start on a straw core ontologization. What I'd need is people 
>> to comment on the concepts and properties there, and tell me whther 
>> they can formalize their discriminators with it/tell me whther this is 
>> a valid starting point.
>>
>>  I am sure that only a small part of the discrinminators can be 
>> coevered so far, but, as we get going we could get this forward in 
>> mutual feedback iterations. (A timeplan of periodic iterations 
>> wouldn't be too bad...)
>>
>>  This is certainly only one approach, but the one I suggest to get going.
>>
>>> (2) Section 5,  Discriminators for Event-Condition-Action (ECA) 
>>> Rules. The discriminators listed here may not include all those that 
>>> are of interest, and may not necessarily structure them in the best 
>>> way. For example, the list for 5.2.7, "Which type of event 
>>> specification is used in the language?" lists as the set of possible 
>>> choices algebraic, linear temporal logic, event calculus, and other.  
>>> Linear temporal logic is an entirely different animal from the event 
>>> calculus. A better structure might compare linear temporal logic with 
>>> languages that have explicit notions of action and causation; this 
>>> class of languages include situation calculus, fluent calculus, and 
>>> event calculus, among many others. As another example, it may be 
>>> useful to distinguish between languages that explictly mention time 
>>> points and/or intervals from those that don't. This important 
>>> concept, which one would expect to find in an ontology of ECA 
>>> languages (and indeed, in an ontology of time), is not implicit in 
>>> this set of discriminators.
>>
>>
>>
>> I agree that we don't yet have a clear picture of what "event" and 
>> "action" etc. mean, i.e. what makes an event different from a 
>> condition, is on a subclass of the other, etc. I would see this as the 
>> next iteration step and see first how many discriminators we can cover 
>> with a small bunch of concepts...
>>
>>> What all of this serves to underscore is that our job in ontologizing 
>>> the RIFRAF is not merely to decide how to structure the 
>>> discriminators that exist, but to try to collect as many possibly 
>>> relevant discriminators as we can. How we proceed in this enterprise 
>>> is something that we ought to discuss.
>>
>>
>>
>> My thought on how to structure it was really on top of a CORE 
>> ontologization which we carefully extend.
>>
>> I think these two things should really be kept separate:
>>
>> 1) I "core ontology" of terms used to express features of rules, 
>> rulesets, languages and systems.
>>
>> 2) Formalizations of the "discriminators" by means of these features.
>>
>> Opinions, comments welcome...so, if you could have a look on the straw 
>> owl file I posted, we could improve it.
>>
>> Sandro, can we use some W3c hosted server for subversioning or CVS for 
>> this? (would make sense in my opinion), if somebody has better 
>> experience in other tools than protege/CVS for collaboratively doing 
>> OWL ... let me know!)
>>
>> axel
>>
>>
>>
>>> *Axel Polleres <axel.polleres@urjc.es>*
>>> Sent by: public-rif-wg-request@w3.org
>>>
>>> 01/22/2007 07:42 PM
>>> Please respond to
>>> axel
>>>
>>>
>>>     To
>>>     W3C RIF WG <public-rif-wg@w3.org>
>>> cc
>>>     Subject
>>>     Re: [RIFRAF] ho to proceed? Part I: Ontologization
>>>
>>>
>>>    
>>>
>>>
>>>
>>>
>>>  > 1) First, I will try to get something towards ontologization out 
>>> of the
>>>  > whole core discussion, and raise some open questions there.
>>>
>>>
>>> We agreed that several people take over parts of the ontologization
>>> according to the sections of the questionnaire [3].
>>>
>>>   Supposedly, an overall ontology on what is a rule, condition, head,
>>> body, etc. would be a starting point for axiomatizing the
>>> discruiminators mentioned there.
>>> Thus, for giving it a start, I concentrated to modeling conditions and
>>> what is currently in the core properly for the moment.
>>>   I picked up a rudimentary attempt by Sandro [1] and started to
>>> additionally "OWLify" what I found in the last core version [2].
>>> Find the result as an attachment.
>>> If you think this approach makes sense, we could maybe further develop
>>> this jointly using subversioning or similar versioning software...
>>>
>>>
>>> Just to demonstrate why I think this is a valid starting point for
>>> defining axioms concerning discriminators in the current RIFRAF,
>>> and in which direction this could go let's look at the following
>>> question/discriminator from [3]:
>>>
>>> "1.2 Predicate Variables Permitted vs. Not Permitted
>>> Does your language allow predicate variables? [...]"
>>>
>>> This could be "axiomatized" somewhat as follows using the basic
>>> ontology started now by stating (I use some F-Logic-style syntax here,
>>> just to get to the point, hope it is readable enough):
>>>
>>> =======================================================================
>>> % Axiomatizing 1.2 in the rifraf ontology:
>>>
>>> % PredVarNotPermitted is a subclass of Language
>>> predVarNotPermitted::Language.
>>>
>>>
>>> % Define an  auxiliary predicate to "collect" recursively
>>> % all "subConditions":
>>>
>>> forall C, C1. C[hasCondition -> C1] implies C[hasSubCondition -> C1]
>>>
>>> forall C. C[hasCondition -> C1[hasSubCondition -> C2] implies
>>>             C[hasSubCondition -> C2]
>>>
>>>
>>> % Finally the rule which disallows variales for the
>>> % predVarNotPermitted languages:
>>>
>>> forall L, R,C,F.
>>> ( L:predVarNotPermitted and
>>>    R[hasRecCondition->C:ComplexTerm[hasFunctor->F:Variable]]
>>> )
>>> implies
>>> neg R[expressibleIn->L]
>>> =======================================================================
>>>
>>>   Main open issues are:
>>>
>>> a) Well, this probably looks a lot like Sandro's attempts to make an
>>> abstract syntax notation which is not surprising.
>>>
>>> b) I came to some limits very quickly, e.g.
>>>    How do I express that a parameter has at least one position or 
>>> functor
>>>    describing the argument-name. This can be done in OWL, but not in
>>>    protege (without adding a new class). Likewise, I am unsure whether
>>>    the 1.2 axiomatization above can be encoded in OWL properly.
>>>
>>> c) Is this exercise useful or shall we wait until we have the core
>>>     fixed before continuing?
>>>     For instance: When we go further towards e.g. events, one has to ask
>>>     him/herself for instance whether events are a subclass of 
>>> "condition"
>>>     or something different? How can I axiomatize in an extensible way
>>>     that Core rule has no events in its body, etc.
>>>     It seems to me that for expressing this, I need integrity 
>>> constraints
>>>     not expressible in OWL...
>>>
>>> FWIW, I would like to discuss the general approach before continuing,
>>> honestly.
>>>
>>> best,
>>> axel
>>>
>>> 1. http://lists.w3.org/Archives/Public/public-rif-wg/2006Oct/0093
>>> 2. http://www.w3.org/2005/rules/wg/wiki/CORE?action=recall&rev=14
>>> 3. http://www.w3.org/2002/09/wbs/38457/RAFQuestionnaire/
>>>
>>> -- 
>>> Dr. Axel Polleres
>>> email: axel@polleres.net  url: http://www.polleres.net/

-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/




Received on Wednesday, 21 February 2007 09:41:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:42 UTC