Re: Reference vs import <-- RIF Core shortened

Christian de Sainte Marie wrote:
> 
> Michael Kifer wrote:
>>
>> I don't see how Java objects and external schemas relate to allowing # 
>> and ##
>> in RIF-Core facts.  I would like to see a clarification from you on 
>> that issue
>> and Gary's view.
> 
> I don't see that either: as I have said repeatedly, # and ## facts need 
> not be asserted, if there is an external schema, as far as I understand 
> (but, of course, we need to have a way to import and refer to that 
> external schema).
> 
> There is one thing that is not clear to me: does Core want (need, 
> require) # or ## facts?

> Sometimes, you sound like it is a demand from PRD, whereas I was under 
> the impresion that it was a demand from Core...

No.

> And, btw, does Core want them in rule heads?

 From my point of view # and ## are of little value (in Core, or in BLD 
for that matter) for any of my use cases and the divergence between ## 
and rdfs:subClassOf will cause us some support problems. So if Core 
dropped both of them in their entirety that would be just fine by me!

However, we want Core to be useful to as many people as possible (to 
within the constraints of it being "simple" and a subset of both PRD and 
BLD).

Gary has argued that so many PR systems expect rules to test[*] the type 
of an object that not having # in rule conditions would mean that 
virtually no PR systems could exchange rules using Core.

If that's right then we ought to have at least # in Core and two 
questions arise:
  - where can # be used?
  - do we also need ##?

 From a BLD perspective it makes most sense for Core to either have both 
# and ## unrestricted or not have them at all.

However, from a PRD perspective they are special because you can't 
assert them and ## is much less frequently used in conditions. So all 
the requests to limit where #/## can occur are coming from the 
requirement of PRD compatibility.

We have three options:

(1) Don't have # or ## at all. Nice and simple.  However, if Gary's 
position is right this would make Core largely useless for production 
rule interchange.

(2) Have # and ## unrestricted as in BLD. An internally consistent 
position. However, at least in the current state this would violate the 
requirement that Core be a subset of PRD and would raise the cost of 
implementing a typical PR<->Core translator.

(3) Only have # and ## where PRD needs them. Rather arbitrary from a BLD 
point of view but keeps Core as consistent with, and relevant to, PR usage.

We are currently assuming option 3 and so are basically tied to what 
works for PRD.

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!). All requests to change 
that position are coming from PRD, or at least from Gary :-), but I can 
appreciate that only having # in conditions seems pretty useless.

Dave

[*] Whether the need is to test the type of an object or merely declare 
it seems to be disputed between the PRD folks, see: 
http://lists.w3.org/Archives/Public/public-rif-wg/2008Sep/0162.html

-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Friday, 21 November 2008 11:45:05 UTC