W3C home > Mailing lists > Public > public-rif-wg@w3.org > November 2008

Re: Reference vs import <-- RIF Core shortened

From: Gary Hallmark <gary.hallmark@oracle.com>
Date: Mon, 24 Nov 2008 09:18:15 -0800
Message-ID: <492AE1D7.6010606@oracle.com>
To: Chris Welty <cawelty@gmail.com>
CC: Patrick Albert <palbert@ilog.fr>, RIF WG <public-rif-wg@w3.org>

Surely there is some overlap in the notions of member and subclass that 
could be considered Core.  Pushing for as small a Core as possible 
strikes me as the wrong approach.

Chris Welty wrote:
> Patrick Albert wrote:
>> I do support :)!
> What is it you support?  A restricted notion in CORE of the BLD member 
> and subclass?
>> I believe that PRD needs to support an object model such as the one
>> found in the UML class diagram. It is very simple and obvious --
>> classes, subclasses, attributes and links with cardinality
>> specifications -- every software developer knows it or at least has been
>> exposed to it, it is supported by many tools, and every Business Rules
>> system supports it.
> Certainly the notion of member and subclass in BLD is not the same as 
> the one in UML, so if this is the objective BLD and PRD have a 
> different notion of class and subclass.
>> The problem I see though to have it in CORE, is the set-based
>> interpretation of the inter-objects links, when the BLD frames have a
>> one-tuple-at-a-time interpretation. 
> I have no idea what you mean by this, but perhaps it doesn't matter.  
> It seems to me the point is that they are *different*, in which case 
> they don't belong in CORE.
> I am not intending to express an opinion here, just trying to congeal 
> the threads.  We have a resolution in the group about "no hidden 
> features" which I intend to uphold - that is that no part of the 
> syntax will be reused *to mean something different*.
> So, it seems to me that while the similarities between what I'll call 
> prd:subclass/prd:member and bld:subclass/bld:member are intruiging, 
> there are differences - they are not the same thing so there is no 
> "CORE" notion.
> -Chris
>>  Patrick.
>> -----Original Message-----
>> From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
>> On Behalf Of Chris Welty
>> Sent: dimanche 23 novembre 2008 03:07
>> To: RIF WG
>> Subject: Re: Reference vs import <-- RIF Core shortened
>> 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:28:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:53 UTC