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

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. 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/

Received on Monday, 10 December 2007 18:41:46 UTC