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

RE: Reference vs import <-- RIF Core shortened

From: Patrick Albert <palbert@ilog.fr>
Date: Mon, 24 Nov 2008 19:41:08 +0100
Message-ID: <4412C4FCD640F84794C7CF0A2FE890D2F194D6@parmbx02.ilog.biz>
To: "Gary Hallmark" <gary.hallmark@oracle.com>, "Chris Welty" <cawelty@gmail.com>
Cc: "RIF WG" <public-rif-wg@w3.org>

1/ The minimal support is class membership: a variable in PR Systems is
typed by the name of a class or a primitive type, the class has to be a
constant, as in classical programming languages. If one cannot express
that in core, then there is not much left in it. In this sense, class
membership is a prerequisite rather than a plus.



2/ my point is about pattern matching in the BLD frames. 


If the slots refers to a set, such as 'parents', BLD will unify one
element of the set at a time: one parent at a time, such as for example
in: ?H:Human(age->15 && father->?Y && parents->?Z). 


In PRD the matching is different. A PRD rules exploits the cardinality
found in the object model. The matching would refers to the value of the
slot - the set of all the parents - and the membership test has to be
explicit, such as for example in: ?H:Human(age = 15 && father = ?Y && ?Z
in parents)





-----Original Message-----
From: Gary Hallmark [mailto:gary.hallmark@oracle.com] 
Sent: lundi 24 novembre 2008 18:18
To: Chris Welty
Cc: Patrick Albert; RIF WG
Subject: Re: Reference vs import <-- RIF Core shortened


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

>> exposed to it, it is supported by many tools, and every Business

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

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


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


>>>> import can be specified without requiring that subclass


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


>>> importers that output standard RIF so it can be used with all the 

>>> current and future RIF translators (assuming the RIF dialect

>> #

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


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


>>>> 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 18:42:50 UTC

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