RE: Reference vs import <-- RIF Core shortened

Comments in the text.

Changhai

-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Christian de Sainte Marie
Sent: Friday, November 21, 2008 1:44 PM
To: Dave Reynolds
Cc: kifer@cs.sunysb.edu; Paul Vincent; Gary Hallmark; Patrick Albert;
Boley, Harold; Adrian Paschke; Axel Polleres; RIF WG
Subject: Re: Reference vs import <-- RIF Core shortened


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.

CKE: Completely agreed.

Hence, (my current understanding is that) PRD can do without ## in the
concrete syntax.

CKE: Agree.

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

CKE: I see almost no case. It's sometimes useful to test that an object
is an instance of some class, but very very rarely that a class is a
subclass. It's typically the kind of superfluous feature that we can
skip on.

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

CKE: If we want to offer tags to describe an object model (instead of
importing it), we need a way to describe classes, subclasses,
attributes, etc. But again, it's the kind of superfluous feature we can
avoid. Most of the cases, we are importing an external model.

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

CKE: Almost never, a part in the constraint systems, where in the rule
actions, you affirm that the class of an object is yet more specialized.
It's again a feature that we can reserve for PRD version N, when we'll
be broadening the PRD's application domains to other related
technologies.

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

CKE: 100% agreed. 

Hence, (my current understand is that) PRD can do with # being allowed
in tests and variable bindings only.

CKE: Agreed.

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

CKE: Before we mute the class of an object, we need a whole discussion
about what are the classes. This discussion has never happened, and we
won't agree so quickly. We have more or less implicitly agreed that
classes come from immutable worlds like Java or XSD, they are the most
widely used. So I think we should leave deliberately the question of
class mutation for later.


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

Received on Friday, 21 November 2008 14:02:05 UTC