RE: Reference vs import <-- RIF Core shortened

 

1/ The minimal support is class membership: a variable in PR Systems is
typed by the name of a class or a primitive type, the class has to be a
constant, as in classical programming languages. If one cannot express
that in core, then there is not much left in it. In this sense, class
membership is a prerequisite rather than a plus.

 

 

2/ my point is about pattern matching in the BLD frames. 

 

If the slots refers to a set, such as 'parents', BLD will unify one
element of the set at a time: one parent at a time, such as for example
in: ?H:Human(age->15 && father->?Y && parents->?Z). 

 

In PRD the matching is different. A PRD rules exploits the cardinality
found in the object model. The matching would refers to the value of the
slot - the set of all the parents - and the membership test has to be
explicit, such as for example in: ?H:Human(age = 15 && father = ?Y && ?Z
in parents)

 

 Patrick.  

 

 

-----Original Message-----
From: Gary Hallmark [mailto:gary.hallmark@oracle.com] 
Sent: lundi 24 novembre 2008 18:18
To: Chris Welty
Cc: Patrick Albert; RIF WG
Subject: Re: Reference vs import <-- RIF Core shortened

 

Surely there is some overlap in the notions of member and subclass that 

could be considered Core.  Pushing for as small a Core as possible 

strikes me as the wrong approach.

 

Chris Welty wrote:

> 

> 

> 

> Patrick Albert wrote:

>> I do support :)!

> 

> What is it you support?  A restricted notion in CORE of the BLD member


> and subclass?

> 

>> 

>> I believe that PRD needs to support an object model such as the one

>> found in the UML class diagram. It is very simple and obvious --

>> classes, subclasses, attributes and links with cardinality

>> specifications -- every software developer knows it or at least has
been

>> exposed to it, it is supported by many tools, and every Business
Rules

>> system supports it.

> 

> Certainly the notion of member and subclass in BLD is not the same as 

> the one in UML, so if this is the objective BLD and PRD have a 

> different notion of class and subclass.

> 

>> The problem I see though to have it in CORE, is the set-based

>> interpretation of the inter-objects links, when the BLD frames have a

>> one-tuple-at-a-time interpretation. 

> 

> I have no idea what you mean by this, but perhaps it doesn't matter.  

> It seems to me the point is that they are *different*, in which case 

> they don't belong in CORE.

> 

> I am not intending to express an opinion here, just trying to congeal 

> the threads.  We have a resolution in the group about "no hidden 

> features" which I intend to uphold - that is that no part of the 

> syntax will be reused *to mean something different*.

> 

> So, it seems to me that while the similarities between what I'll call 

> prd:subclass/prd:member and bld:subclass/bld:member are intruiging, 

> there are differences - they are not the same thing so there is no 

> "CORE" notion.

> 

> -Chris

> 

> 

> 

>> 

>> 

>> 

>>  Patrick.

>> 

>> 

>> -----Original Message-----

>> From: public-rif-wg-request@w3.org
[mailto:public-rif-wg-request@w3.org]

>> On Behalf Of Chris Welty

>> Sent: dimanche 23 novembre 2008 03:07

>> To: RIF WG

>> Subject: Re: Reference vs import <-- RIF Core shortened

>> 

>> 

>> 

>> I certainly see the intuition for member and subclass in Core, but it

>> appears its support has diminished to a) only Gary and b) only for a 

>> restricted

>> version of them.

>> 

>> Is this accurate?

>> 

>> -Chris

>> 

>> 

>> Gary Hallmark wrote:

>>> challenge accepted, so below

>>> 

>>> Christian de Sainte Marie wrote:

>>>> Dave,

>>>> 

>>>> thanx for the clarification.

>>>> 

>>>> Here is how I understand PRD needs, at this point. Please, all, 

>>>> complete and/or correct me:

>>>> 

>>>> 1. Production rules needs subclass relationships. But in most, if
not

>> 

>>>> all, cases, the class hierachy is fixed and there is, therefore, no


>>>> need to test it explicitely. However, it may be used by

>> classification

>>>> tests, and it is, thus, needed in the semantics. Since it is, in

>> most,

>>>> if not all, cases, externally defined, it has to be imported. But
the

>> 

>>>> import can be specified without requiring that subclass
relationships

>> 

>>>> be explicitely asserted in rules or facts.

>>>> 

>>>> Hence, (my current understanding is that) PRD can do without ## in

>> the

>>>> concrete syntax.

>>> very odd to have ## in the abstract syntax and semantics but not let


>>> people use it.

>>>> So, it would be interesting to challenge that assertion:

>>>> 

>>>> 1a. What would be an use case where a subclass relationship test

>> would

>>>> need be explicit in the condition of a rule (as opposed to the test


>>>> being carried silently as a consequence of importing the class 

>>>> hierarchy)?

>>> Here's a production rule I'd very much like to write if I'm trying 

>>> to translate between RDF and Java objects:

>>> 

>>> if ?o # ?c1 and ?o # ?c2 and not(?c1 = ?c2 or exists( ?c ?o # ?c and

>> ?c

>>> ## ?c1 and ?c ## ?c2))

>>> then ConstraintViolation("found an object that cannot have a Java

>> Object

>>> Model")

>>>> 1b. What would be an use case where a subclass relationship would

>> need

>>>> be explicitely asserted in a fact (as opposed to being taken into 

>>>> account as a consequence of importing the class hierachy)?

>>> Let's say several vendors have RIF translators but not all have an 

>>> import mechanism that works for Java objects, XML documents, and OWL


>>> ontologies.  An enterprising vendor could build a comprehensive set
of

>> 

>>> importers that output standard RIF so it can be used with all the 

>>> current and future RIF translators (assuming the RIF dialect
supports

>> #

>>> and ## facts, of course)

>>>> 1c. What would be an use case where a subclass relationship would

>> need

>>>> be asserted as a consequence of a rule (as opposed to the class 

>>>> hierachy being immutable)?

>>> I don't want to support this

>>>> 2. Production rules need to test membership relationships, though.

>> But

>>>> in most, if not all, cases, class membership is immutable. So that 

>>>> class membership needs be asserted only at an object's creation. It


>>>> can thus be part of the semantics of the creation action (e.g. as 

>>>> proposed in [1]).

>>>> 

>>>> Hence, (my current understand is that) PRD can do with # being

>> allowed

>>>> in tests and variable bindings only.

>>> No, we need # and ## as facts to support the Import Vendor use case.

>>>> The only challenge to that assertion that I can imagine would be an


>>>> use case for class membership assignement or mutation as a

>> consequence

>>>> of a rule (but you all know how poor my imagination :-)

>>> I don't want to support # and ## as conditional assertions, only as 

>>> facts (i.e. unconditional)

>>>> 2a. What would such an use case look like?

>>>> 

>>>> 2b. Other ways to challenge the assertion, anyone?

>>>> Dave Reynolds wrote:

>>>>> The proposal we discussed some weeks ago (but seem never to have 

>>>>> formally adopted) was to only have # and only in rule conditions. 

>>>>> That is appealing to be me because then I don't have to implement 

>>>>> anything (if you can't assert data you can't test it!).

>>>> The semantics of PRD is specified with respect to a data source.
But,

>> 

>>>> as far as I understand, it does not require the data to be

>> explicitely

>>>> asserted as facts (as opposed to being imported by reference to the


>>>> data source). So that, as soon as we will have specified that
import,

>> 

>>>> it will be possible, in PRD at least, to have facts to test class 

>>>> membership, whether PRD allows to assert facts or not...

>>>> 

>>>> Cheers,

>>>> 

>>>> [1] http://www.w3.org/2005/rules/wiki/Alt_AbstrAction

>>>> 

>>>> Christian

>>>> 

>>> 

>> 

>