Re: RIF Core shortened

Core (and thus BLD and PRD) needs to be able to represent facts and 
rules.  Here are some examples of facts:

eg:P(1)

_o # eg:Class1

_o[eg:property1->"red"]

eg:Class1 ## eg:SuperClass1

One can give semantics to a ruleset that imports an xml document containing:

<eg:Class1 xsi:schemaLocation=mySchemaURI>
  <eg:property1>red</eg:property1>
</eg:Class1>

where mySchemaURI refers to an xml schema document containing
<complexType name="SuperClass1">
  <element name="property1"/>
</complexType>
<element name="Class1" type="SuperClass1"/>

The semantics is defined by translating to facts (in fact, the last 3 
example facts above).

If you like that way of defining xml data, then it lends extra weight to 
the argument that core must support facts.  But even if you don't like 
that way of defining xml data, it does not diminish the seemingly 
obvious requirement that core should support facts.

This leads to a proposal: Core allows # and ## in rule conditions and in 
facts.

BTW, we discussed External(#) and External(##) several times but it 
doesn't help because
a. they aren't legal in BLD, thus BLD would have to change for these to 
be in core
b. we need "internal" # and ## rather than External to represent object 
facts.

Christian de Sainte Marie wrote:
> Gary, all,
>
> Could you back up a little bit for me, please? I am not on the Core 
> mailing list, and I might have missed part of the discussion.
>
> Gary, you say that you need to assert membership and subclass 
> relationships in order to  "map (schema valid) XML documents to 
> frames". I assume that, when you talk about mapping XML document to 
> frames, you refer to your strawman proposal for mapping XML schema 
> valid XML data to RIF frames [1]: is that correct?
>
> If yes, I do not understand why you say that it would require that # 
> and ## by assert, conditionally or inconditionally? Can you 
> (re-)explain that part, please?
>
> On the other hand, I am assuming, also, that when class membership and 
> the class hierarchy are specified in an external XML schema (which is 
> what [1] is about), # and ## are effectively processed as if they were 
> External, that is: they need not be asserted to be true; and they 
> cannot be asserted (not in a core PR system, at least).
>
> Is that the key?
>
> If yes, isn't the solution to allow # and ## as Externals: External 
> are not allowed in the conclusion, but logical (or local) # and ## are.
>
> That would resolve the question, as far as I understand, and since 
> what can be External is at risk in BLD, we need not come back before 
> LC to change it, and thus we can have that in Core (if Core wants it; 
> Core wants only logical # and ##, no pb either: External # and ## are 
> an extension for PRD, and maybe BLD. If Core wants only External # and 
> ##, no pb, again: PRD will be happy with that, and BLD can extend to 
> logical # and ## if needed)...
>
> Or am I beside the point?
>
> Cheers,
>
> Christian
>
> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Oct/0046.html
> Gary Hallmark wrote:
>
>>
>> I think we don't have to distinguish "creation" vs. "modification" 
>> for unconditional conclusions (aka facts).  It seems the worst thing 
>> that happens is we have to translate
>>
>> _o # eg:class1
>> _o # eg:class2
>>
>> The translator can always look ahead at *all* the facts before 
>> deciding what to do.  In this case, the translator searches for a 
>> constructor (taking no arguments) that can create an instance of 
>> eg:class1 *and* eg:class2.  Because we allow # only in unconditional 
>> conclusions, this kind of lookahead is always easy and possible.
>>
>> Michael Kifer wrote:
>>
>>> On Mon, 17 Nov 2008 15:06:02 +0100
>>> "Patrick Albert" <palbert@ilog.fr> wrote:
>>>
>>>  
>>>
>>>> Right, this task stretches us a little too much... :-/
>>>> I am happy to support your proposal "allow # and ## in Core in rule
>>>> conditions and *unconditional* rule conclusions" as long as in the
>>>> "unconditional conclusions" we limit ourselves to the creation of new
>>>> objects, not including the modification of the class of an already
>>>> existing object.     
>>>
>>>
>>> The latter (creation vs modification) is not possible to define in 
>>> the core.
>>>   
>>
>>
>>
>>
>
>

Received on Monday, 17 November 2008 19:05:00 UTC