RE: Reference vs import <-- RIF Core shortened

Patrick and all,

We need to support 2 use cases, at least for PRD. Suppose that in my
rules I references two classes: Customer and ShoppingCart.

Use case 1: Implicit type referencing

The sender of the rule interchange document knows those 2 classes, and
the receiver too. Both application work on a same object model. The
transitive closure of the class hierarchy can be deep. When exchanging
rules, you would simply serialize the rules without any class
description. You know perfectly that the receiving application has the
same classes.

Use case 2: Explicit type information

The receiving application does not have type information, and you want
to make the document really autonomous, it will contain rules, and also
the classes.

The use case 2 raises a series of questions, such as which class
description to use, how can the names in the rules reference the names
in the class descriptions, etc. So I think we first need to support use
case 1, maybe it's enough for a first version.

Changhai

-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Patrick Albert
Sent: Monday, November 24, 2008 9:35 AM
To: Chris Welty; RIF WG
Subject: RE: Reference vs import <-- RIF Core shortened


I do support :)!

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.

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 feel a little stupid here but I
don't see how to reconcile both.



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

-- 
Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
http://www.research.ibm.com/people/w/welty

Received on Monday, 24 November 2008 10:18:05 UTC