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

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

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Fri, 07 Dec 2007 10:04:27 -0500
To: "Paul Vincent" <pvincent@tibco.com>
Cc: axel@polleres.net, "Public-Rif-Wg \(E-mail\)" <public-rif-wg@w3.org>
Message-ID: <1914.1197039867@cs.sunysb.edu>


Paul,
this is indeed about BLD, not PRD.


	--michael  


> > 1. It imposes additional axioms, which are not commonly accepted.
> 
> > 2. It is also not even defined for classes specified using function
> terms
> 
> >    (like list(?Foo)).
> 
> >=20
> 
> > Both arguments are also applicable to the RDF membership relationship.
> 
> >=20
> 
> > I am convinced that throwing out these primitives serves no purpose
> and
> 
> > will just gratuitously cripple the BLD.
> 
> =20
> 
> 1. My take on this is that if there is at least one objection to using a
> specific language definition (ie RDFS) for a RIF feature (ie BLD) then,
> as RIF is meant to be language-neutral, then the language-specific
> feature cannot be included as-is.
> 
> =20
> 
> 2. On an operational aspect, I assume we are still talking about "class
> membership" as opposed to other "membership" aspects like list/array
> membership. So this discussion does NOT impact PR rules like the
> following:
> 
> =20
> 
> If
> 
>      Rulevariable Customer // TIBCO declaration, ILOG rule variable,
> Blaze pattern, etc
> 
>      Customer.accountNumber is a member of the array Fraudcases
> 
> Then
> 
>      // actions on relevant Customer object
> 
> =20
> 
> > > 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.)
> 
> =20
> 
> [My regrets too, as I have a conflict with an early OMG Tech Meeting on
> Tues.]
> 
> =20
> 
> Cheers
> 
> =20
> 
> Paul Vincent
> 
> TIBCO | ETG/Business Rules=20
> 
> =20
> 
> > -----Original Message-----
> 
> > From: public-rif-wg-request@w3.org
> [mailto:public-rif-wg-request@w3.org]
> 
> > On Behalf Of Michael Kifer
> 
> > Sent: 07 December 2007 05:54
> 
> > To: axel@polleres.net
> 
> > Cc: Public-Rif-Wg (E-mail)
> 
> > Subject: Re: Reminder: pending discussion "membership" (pending
> discussion
> 
> > on ACTION-350)
> 
> >=20
> 
> >=20
> 
> >=20
> 
> >=20
> 
> > 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.
> 
> >=20
> 
> > First, one needs to be able to specify that one class is a subclass of
> 
> > another class **as part of the KB**. For instance,
> 
> >=20
> 
> > student##person.
> 
> > father(person)##person.
> 
> >=20
> 
> > In KB apps this is used for reasoning, not just as part of a data
> 
> > model. How would one specify this info otherwise?
> 
> >=20
> 
> > Here is a more sophisticated example: parametrised lists.
> 
> >=20
> 
> > list(?Subclass) ## list(?Super) :- ?Subclass ## ?Super.
> 
> >=20
> 
> > (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.)
> 
> >=20
> 
> > RDF's subclassOf does not cut it because
> 
> >=20
> 
> > 1. It imposes additional axioms, which are not commonly accepted.
> 
> > 2. It is also not even defined for classes specified using function
> terms
> 
> >    (like list(?Foo)).
> 
> >=20
> 
> > Both arguments are also applicable to the RDF membership relationship.
> 
> >=20
> 
> > I am convinced that throwing out these primitives serves no purpose
> and
> 
> > will just gratuitously cripple the BLD.
> 
> >=20
> 
> >=20
> 
> >     --michael
> 
> >=20
> 
> >=20
> 
> >=20
> 
> > > 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/
Received on Friday, 7 December 2007 15:05:10 GMT

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