Re: Reference vs import <-- RIF Core shortened

I do not think it is accurate.  Almost all production rules have a 
notion of pattern, and this corresponds to the conjunction of a 
membership formula and a frame formula.  If Core has no membership 
notion at all, then almost no production rule will also be a Core rule. 
This makes Core embarassingly small, and that makes us look like we have 
not tried hard enough to interoperate between the production rule and 
logic rule communities. 

Chris Welty wrote:
>
>
> 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
>>>
>>
>>
>

Received on Monday, 24 November 2008 17:27:45 UTC