- From: Adrian Paschke <Adrian.Paschke@gmx.de>
- Date: Sun, 16 Nov 2008 22:15:47 +0100
- To: cleo@us.ibm.com, gary.hallmark@oracle.com, Harold.Boley@nrc-cnrc.gc.ca, kifer@cs.stonybrook.edu
- Cc: public-rif-wg@w3.org
Stella, Gary, (and Michael and Harold),
I already incorporated most of your comments in the new version of RIF UCR.
You both noted for use case 4.2
http://www.w3.org/2005/rules/wiki/UCR#Negotiating_eCommerce_Transactions_Through_Disclosure_of_Buyer_and_Seller_Policies_and_Preferences
that there are many places that use "nested frame syntax" and that this is illegal, e.g., ex:provide("eShop" ?buyer[ex:card->?x ex:addr->?y]).
However, the proposed solution
And(
?buyer[ex:card->?x ex:addr->?y]
ex:provide("eShop" ?buyer)
)
is incorrect, too. It would mean that we need two facts to fire the rule (for a production rule) or prove the two goals (for derivation rules).
Moreover, the formalization of the rules without nested frames (or nested functions) becomes very verbose, as you can see in 4.2. For instance, the definition of the customer object "Alice" which becomes a very complicated rule without nested frames.
ex:Alice[ex:card -> ?card ex:deliveryAddr -> ?deliveryAddr] :-
?Date = ex:Date[ex:month -> 12 ex:year -> 2012]
?Person = ex:Person[ex:lastname -> "Sure" ex:firstname -> "Alice"]
?Street = ex:Street[name -> "North Street" number -> 111]
?card= ex:Card[ ex:type -> "Visa"
ex:holder -> ?Person
ex:number -> "123456789"
ex:code -> "123"
ex:expiry -> ?Date
]
?deliveryAddr = ex:DeliveryAddress[ ex:name -> ?Person
ex:street -> ?Street
ex:postal_code -> "NE3456"
ex:city -> "New York"
ex:country -> "USA"
]
Any ideas?
-Adrian
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Received on Sunday, 16 November 2008 21:16:27 UTC