- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Wed, 5 Nov 2003 17:04:44 -0500
- To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
- Cc: phayes@ihmc.us, public-sw-meaning@w3.org
On Friday, October 31, 2003, at 12:59 PM, Peter F. Patel-Schneider wrote: [snip] >> Subject: Re: in defense of standards >> From: Peter F. Patel-Schneider <pfps@research.bell-labs.com> >> To: sandro@w3.org >> Cc: bparsia@isr.umd.edu, public-sw-meaning@w3.org >> Date: Fri, 10 Oct 2003 11:26:03 -0400 (EDT) >> >> From: Sandro Hawke <sandro@w3.org> >> Subject: Re: in defense of standards >> Date: Fri, 10 Oct 2003 11:07:50 -0400 >> >> [...] >> >>> What kind of statement do you imagine we might produce? Would it >>> talk >>> about people and software agents and what they may/should/must do? >>> >>> -- sandro >> >> Well, since you ask, I imagine that we could produce a three-part >> statement: >> >> 1/ The SW meaning of a set of SW documents in a SW language is >> completely >> determined from the normative specification of the SW language and >> the >> contents of these SW documents. Doesn't this leave open what we should stick in those normative specifications? >> 2/ The meaning of a set of SW documents does not necessarily include >> any of >> the meaning of any other document, except for those SW documents >> whose >> meaning is explicitly required to be a part of the meaning of the >> SW >> documents by the normative specification of the SW language and the >> contents of these SW documents. I like this, though it does seems to defer some of the issues at hand. E.g., on thing one might thing Tim is concerened with is the paucity of specification of the relationship between SW documents in RDF, and perhaps even in OWL. >> 3/ Applications are free to augment this meaning, perhaps by >> including the >> meaning of other SW documents, but are prohibited from indicating >> that >> this augmented meaning is part of the meaning that comes from the >> SW >> language. >> >> So, as far as RDF is concerned, the meaning of a set of SW documents >> in >> RDF/XML is determined solely from the RDF graph that results from the >> parsing of these documents and is not dependent on the contents of >> any other document. OWL extends this to bring in the meaning of >> imported documents. Sounds good to me. I've come round. I take one 1 and 2 as truisms (though perhaps 2 is tendencious). Well, 3 too :) If one doesn't like how documents and graphs and meanings relate given the current specificiations, it seems straightforward what objections to raise. To side step the imports/SOC issue for a moment, these seem to reduce (given the current specs) to "The spec sanctioned meaning ('SW meaning', I suppose) of an RDF (or OWL) document is the formal meaning of the graph resulting from parsing (or parsing + imports closure of) the document. This, of course, doesn't mean actual applications (by 3) need to treat RDF (or OWL) documents as uninterpreted except for the logical vocabulary (although an awful lot will (and fruitfully so)). It does mean, of course, that if applications act in ways that are sensitive to the interpretation of the document, that they are largely on their own (given current specs) in determine which interpretation(s) of that document they ought to go with. This gets as thin as deciding that, for a stock trading agent, that the following is appropriate (prologly) pseudocode bought_stock(B, StockOrder) :- rdf(B, rdf:type, p:Client), rdf(B, p:made, Order), rdf(Order, rdf:type, p:BuyOrSellOrder), rdf(Order, <http://www.example.org/Buy>, StockOrder), rdf(StockOrder, p:number, Nr), rdf(StockOrder, p:symbol, Symbol), buy_stock(B, Symbol, Nr). Where buy_stock_for/3 actually calls the relevant web service (say) that buys, rather than sells the stock. Interestingly, for this example, we can fairly easily narrow down the interpretation of http://www.example.org/Buy by connecting it (in RDF, OWL, and things like OWL-S) to actual code (or a specific web service with a determined behavior). It's pretty clear (pace the rest of the rats' nest of statements and code one would hope would be present in a realistic example) what http://www.example.org/Buy means *in the above code*, especially when you compare it to the similar predicate: sold_stock(B, StockOrder) :- rdf(B, rdf:type, p:Client), rdf(B, p:made, Order), rdf(Order, rdf:type, p:BuyOrSellOrder), rdf(Order, <http://www.perverseexamples.org/#sell>, StockOrder), rdf(StockOrder, p:number, Nr), rdf(StockOrder, p:symbol, Symbol), sell_stock(B, Symbol, Nr). If the last line of sold_stock/2 were "buy_stock(B, Symbol, Nr)" (call this sold_stock_p/2 then surely the (at least, operational) meaning of http://www. perverseexamples.org/#sell would be, ceteris paribus, the same as http://www.example.org/Buy in bought_stock/2. That is, you could replace one with the other with no change in the (behavioral?) semantics of the predicate. Expectations might be different in each case (one prolly should argue that there's a bug in, at least, the names in the second predicate): Clearly, to the casual reader, sold_stock_p/2 is misleadingly named (unless you read "perverse" for the _p, rather than "predicate" :)). Actually, for all we know, sold_stock_p is *correct* and using all the terms as their original coiners intended: Perhaps the predicate author *really wants* to buy when someone puts in a sell order (that's not even far fetched! perhaps buy_stock/3 understands that when the p:BuyOrSellOrder has a http://www.example.org/Buy, it should buy *for* the client, and when it has a http://www.perverseexamples.org/#sell it should buy *from* the client.) [snip several days of not writing due to travel and meetings] Ok, i'm just sending this midstream. Perhaps it'll prove useful to something. Cheers, Bijan.
Received on Wednesday, 5 November 2003 17:03:09 UTC