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

Re: Reminder: pending discussion "membership" (pending discussion on ACTION-350)

From: Axel Polleres <axel.polleres@deri.org>
Date: Tue, 11 Dec 2007 09:26:17 +0000
Message-ID: <475E57B9.8040805@deri.org>
To: Michael Kifer <kifer@cs.sunysb.edu>
CC: Jos de Bruijn <debruijn@inf.unibz.it>, axel@polleres.net, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Michael Kifer wrote:
> Jos,
> 
> It seems that no amount of arguments can convince either side, and others
> (I suspect) simply press the "Delete" button when they see our messages.
> So, we are probably wasting time and are spamming the list.
> Instead, I propose to back up and take a look at the original goals (which
> were not really spelled out).
> 
> The reason why I am proposing # and ## has nothing to do with defining "yet
> another ontology language". Whether we have #/## or not (and whether you
> want it or not), RIF is going to become "yet another ontology language"
> because this is how things are. People tend to like different styles. A
> recent survey http://dme.uma.pt/jcardoso/sw-survey-2007.pdf shows that over
> 15% of ontology engineers use F-logic or derived languages despite RDF and
> OWL. And there are other non-W3C languages as well. 

I have my doubts whether this takes the ammounts of data into account or 
the number of different ontology files. In the latter case, I haave my 
doubts what is the right measure. Probably a weighted sum which values 
the different ontologies by their actual use would make a more realistic 
picture. Nothing against F-Logic, I love F-Logic, but I simply doubt 
these numbers.

> This survey is hard to
> interpret, and I would not give much weight to the actual numbers, but I
> believe it supports my point about RIF.
 >
> The reason for having # and ## is that if we introduced frames then we
> should complete the cycle and define the most basic object-oriented
> concepts as first class citizens (at the cost of only a few lines in the
> document). Namely, class membership and hierarchies.  This will allow to
> round-trip important classes of object-oriented rule-sets.
> 
> What was the reason to include frames if not to allow object-oriented
> round-tripping? After all, all these things are syntactic sugars. An
> alternative would be to define a bare-bones Datalog and let other people
> worry about embedding their languages into Datalog.
> 
> 
> 	--michael  
> 
>>>>> CSMA had an action to bug me about the ## feature :-)
>>>>> I thought that others might also be interested, so I am including my
>>>>> arguments below.
>>>>>
>>>>> First, one needs to be able to specify that one class is a subclass of
>>>>> another class **as part of the KB**. For instance, 
>>>>>
>>>>> student##person.
>>>>> father(person)##person.
>>>>>
>>>>> In KB apps this is used for reasoning, not just as part of a data
>>>>> model. How would one specify this info otherwise?
>>>>>
>>>>> Here is a more sophisticated example: parametrised lists.
>>>>>
>>>>> list(?Subclass) ## list(?Super) :- ?Subclass ## ?Super.
>>>>>
>>>>> (List of FOOs is a subclass of lists of BARs if FOO is a subclass of
>>>>> BAR. We could have list(father(person)), for example.)
>>>> I have yet to see a real use case for the inclusion of either membership
>>>> or classification in RIF.  One can always create toy examples,
>>> This is a toy example?
>>>
>>>> but I wonder who is actually going to use the features.
>>> I must say that I was taken aback by your assertion about a toy example
>>> above.
>>> I do not want to get personal here, but how many knowledge bases (which
>>> actually work) have you written? Why do you think that you can foresee all
>>> the possible ways people might use object-oriented rules, and why do you
>>> think you are a good arbiter to decide which examples are "toy" and which are
>>> not?
>> I have not written many knowledge bases.  I also cannot claim that I can
>> foresee all possible ways people might use rules.  I also do not think
>> that the possibility that people might use a particular feature in the
>> future is a good reason to include that feature in a language.  There
>> are endlessly many features one can think of, so one would make the
>> language endlessly complex.
>>
>> My choice of the label "toy example" may not have been entirely
>> accurate.  I am looking for examples in which people would need the RIF
>> membership or subclass relation, rather than simply encoding their own
>> membership and subclass constructs which correspond to their own model.
>> It has been argued that the use case for the membership and subclass
>> constructs are the integration of different notions of membership and
>> subclass.  However, I have not seen any such concrete use case so far.
>>
>>>> Are there any use cases for the use of these features for the
>>>> integration of several notions of membership or subclassing?
>>>> In the use cases I've seen so far, everyone encodes its membership or
>>>> subclass relation in his preferred way, but I haven't seen use cases in
>>>> which different notions of membership or subclass are integrated using
>>>> the proposed subclass or membership constructs in RIF.
>>> I do not know if we need such use cases. But it is easy to map other
>>> subclass relationships into ##, as we discussed.
>>>
>>>
>>>>> RDF's subclassOf does not cut it because
>>>>>
>>>>> 1. It imposes additional axioms, which are not commonly accepted.
>>>>   Do you have references to back up this statement?
>>> To provide references to a negation of a universal, I only need to give
>>> examples of systems where this notion is not accepted.
>>>
>>> The fact that rdfs:subClassOf is part of the domain is an idiosyncrasy of
>>> RDF and it needs not be pushed down the throat of every language out there.
>>> E.g., DL-based rile languages like SWIRL or several of the F-logic-based
>>> languages.  Other KBs like LOOM also do not have this. In fact, RDF is the
>>> only one that makes this strange assumption among the KB languages that I
>>> know of.
>> Well, the fact that rdfs:subClassOf is part of the domain does not have
>> serious consequences in most uses.  However, you are right that in most
>> systems the subclass relation itself is not part of the domain.
>>
>> However, I could similarly about the membership and subclass relations
>> you proposed.  Namely, classes are interpreted as elements of the
>> domain, which is also not commonly accepted.  At least not in any
>> DL-based systems.
>>
>> So, this means that the membership and subclass relation you propose can
>> not always be used for the representation of membership and subclass.
>>
>>> Now, reflexivity of the subclass relationship is less controversial.
>>> In fact, when we defined F-logic, we defined the subclass relationship to
>>> be reflexive. But when we started to actually **use** it, we found that in
>>> virtually all cases we had to write something like  ?Foo##?Bar and ?Foo != ?Bar.
>>>
>>>
>>>>> 2. It is also not even defined for classes specified using function terms
>>>>>    (like list(?Foo)).
>>>> What you mean with that?  In an RDF-RIF combination, one can specify the
>>>> example you mentioned in the following way:
>>>>
>>>> student[rdfs:subClassOf -> person].
>>>> father(person)[rdfs:subClassOf -> person].
>>>>
>>>> list(?Subclass)[rdfs:subClassOf -> list(?Super)] :-
>>>> ?Subclass[rdfs:subClassOf -> ?Super].
>>> This is an extension of the RDF notion. Earlier Dave was telling me that to
>>> define class hierarchies one should use RDF or "my preferred data modeling
>>> language" (not sure how to make use of that suggestion).
>>>
>>> Since RDF does not support this, I do not see a point in this exercise.
>>> One could use a property called foobar instead of the above with the same
>>> degree of success.
>>>
>>>
>>>>> Both arguments are also applicable to the RDF membership relationship.
>>>> The RDF membership relationship by itself does not impose additional
>>>> axioms; it is simply a binary relation.
>>>>
>>>> Furthermore, it is certainly defined for classes (and individuals)
>>>> specified using functional terms.
>>> Only in your extension.
>> You seem to say that RDFS is not a powerful enough ontology modeling
>> language?
>> I don't really see this as an argument to replace it, but rather as an
>> argument to extend it (e.g., using the RIF-RDF combination mechanism).
>>
>>>
>>>>> I am convinced that throwing out these primitives serves no purpose and
>>>>> will just gratuitously cripple the BLD.
>>>> I am convinced that including these primitives serves no purpose and
>>>> will gratuitously blow up / complicate the BLD.
>>> By how much does it blow things up?
>> It introduces two additional kinds of atomic formulas, plus some
>> conditions on the semantic structures.  Furthermore, it introduces yet
>> another ontology modeling language for the semantic Web.
>>
>>> There is another issue. Have you studied what would happen when one uses your
>>> RDF-based notion of membership/subclass with the well-founded or stable
>>> semantics?
>> I have only done a preliminary study  for defining a stable model
>> semantics for RIF-RDF combinations.  Complications arise from the blank
>> nodes; however, membership and subclass are rather straightforward.
>> Of course, rdf:type and rdfs:subClassOf are part of the Herbrand
>> universe; then again, so are the constants in all supported datatypes.
>>
>>> Can you voucher that there would be no complications for those
>>> dialects?
>> As I said, I've only seen complications arising from blank nodes.  The
>> definitions of membership and subclass are rather straightforward, so I
>> do not expect any complications there.  Then again, the study was only
>> preliminary.
>>
>> That said, I do not want to force everyone to use RDFS for ontology
>> modeling; I am rather skeptical about the usability of the # and ##
>> constructs as a unifying ontology language.
>>
>> Best, Jos
>>
>>
>>
>>>
>>> 	--michael  
>>>
>>>
>>>
>>>> best, Jos
>>>>
>>>>> 	--michael  
>>>>>
>>>>>
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I was asked by Chris to remind again to forward again a reminder on the 
>>>>>> pending discussion about the special notation '#' for class membership 
>>>>>> and in RIF since this should be discussed in the upcoming Teleconf.
>>>>>>
>>>>>> In the last f2f I was asked to send a use case for this, where I sent 
>>>>>> the - obvious - RDF use case, see
>>>>>> http://lists.w3.org/Archives/Public/public-rif-wg/2007Sep/0184.html
>>>>>>
>>>>>> For your convenience I copy this here again:
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>>
>>>>>> http://www.w3.org/2005/rules/wg/track/actions/350
>>>>>>
>>>>>> The class membership notation '#' is intended to reflect the common
>>>>>> feature of many rule and object oriented languages for being able to
>>>>>> express memebership of a class (or type?)
>>>>>>
>>>>>> A possible use for this is for RDF's rdf:type construct...
>>>>>>
>>>>>> To reflect this in the current RDF/RDFS embeddings, one could add to
>>>>>>
>>>>>> 1) Add to RDF embedding:
>>>>>>
>>>>>>     Forall ?c,?o ?o#?c :- ?o[rdf:type -> ?c]
>>>>>>
>>>>>>
>>>>>> ------- ACTION done, what follows is additional discussion ;-) --------
>>>>>>
>>>>>> This alone, obviously doesn't make too much sense, but in connection
>>>>>> with the additional subclass notation '##' one could safe two rules
>>>>>> in the RDFS embedding:
>>>>>>
>>>>>> 2) Add to RDFs embedding:
>>>>>>
>>>>>>    Forall ?c1,?c2 ?c1##?c2 :- ?c1[rdfs:subclassOf-> ?c2]
>>>>>>
>>>>>> and remove:
>>>>>>    Forall ?x,?y,?z ?z[rdf:type -> ?y] :- And (?x[rdfs:subClassOf -> ?y]
>>>>>> ?z[rdf:type -> ?x]),
>>>>>>    Forall ?x,?y,?z ?x[rdfs:subClassOf -> ?z] :- And (?x[rdfs:subClassOf
>>>>>> -> ?y] ?y[rdfs:subClassOf -> ?z]),
>>>>>>
>>>>>>
>>>>>> In total, the use of the special notation adds two rules and saves us
>>>>>> two rules in the RDF/RDFS embedding.
>>>>>>
>>>>>> Pretty much equals out ;-)
>>>>>>
>>>>>> That's why I am absolutely neutral on whether we chould keep that
>>>>>> feature or no.
>>>>>>
>>>>>> Axel
>>>>>>
>>>>>> p.s.: Note that I have to send regrets for the next Telecon, since I 
>>>>>> will be travelling most likely (could be I get connection from train or 
>>>>>> airport, but no guarantees.)
>>>>>>
>>>>>> -- 
>>>>>> Dr. Axel Polleres
>>>>>> email: axel@polleres.net  url: http://www.polleres.net/
>>>> -- 
>>>> Jos de Bruijn            debruijn@inf.unibz.it
>>>> +390471016224         http://www.debruijn.net/
> 
> 


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

rdf:Resource owl:differentFrom xsd:anyURI .
Received on Tuesday, 11 December 2007 18:31:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:44 GMT