- From: Axel Polleres <axel.polleres@deri.org>
- Date: Tue, 11 Dec 2007 09:26:17 +0000
- 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 UTC