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 08:35:41 UTC