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

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

As I said below, the numbers are hard to interpret. But this does not matter.


	--michael  


> > 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 19:08:28 UTC