Re: Reference vs import <-- RIF Core shortened

Dave Reynolds wrote:
> 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!

I second that: either we allow them, or we don't... all in between makes 
  the core definition weird, IMO. If we don't allow either, at the 
expensof Core being less than what is expressibble in PRD rather than 
more, I am fine with that option.

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


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Friday, 21 November 2008 14:28:40 UTC