- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Fri, 03 Oct 2003 15:40:03 -0400 (EDT)
- To: JohnBlack@deltek.com
- Cc: phayes@ihmc.us, james.lynn@hp.com, public-sw-meaning@w3.org
From: "John Black" <JohnBlack@deltek.com> Subject: RE: Proposed issue: What does using an URI require of me and my s oftware? Date: Fri, 3 Oct 2003 15:11:47 -0400 > > -----Original Message----- > > From: pat hayes [mailto:phayes@ihmc.us] > > Sent: Friday, October 03, 2003 1:48 PM > > To: LYNN,JAMES (HP-USA,ex1) > > Cc: public-sw-meaning@w3.org > > Subject: RE: Proposed issue: What does using an URI require > > of me and my > > s oftware? [...] > > Not naive at all, right on the button. Like, what > > problem are we setting out to solve here? What > > might go wrong that our declarations of Policy > > and Correct Architecture and so on are aiming to > > prevent? I for one am completely unclear what the > > issues are supposed to be that so concern us > > here, and I am extremely worried that we will > > make declarations based on mistaken ideas about > > meaning rather than on any actual problems. > > Ok. ACorp creates a acorp:uri123 which is a serial > number of one of its acorp:StandardWidget, which > is the product ID of its standard widget and has property > listPrice = $2.00 according to its ontology acorp:catalogue. > BCorp, thru their sw-agent, buys a batch of these including > acorp:uri123. Now BCorp turns around and sends the batch to > CCorp's sw-agent with an RDF invoice that states that > acorp:uri123 a ACorp:DeluxeWidget. CCorp can verify that > the list price of a ACorp:DeluxeWidget is $10.00 and happily > pays BCorp their asking price of $5.00. > > Now the RDF invoice used two of ACorps URIs to > commit fraud. Those URIs belong to ACorp and it was never > ACorps intention that acorp:uri123 be called anything other > than a acorp:StandardWidget. How could ACorp make this > clear to CCorp? One solution would be to publish at > acorp:uri123 the statement, this is <> a acorp:StandardWidget. > > Note that this is a boring, trivial example. There is no > inference, semantic search, or other sw-interesting ideas > in it. I'm using it to point out that URIs have > social meanings that will become represented and > communicated by the Semantic Web. BCorp lied. So what? Do you really expect the Semantic Web to prohibit lying? CCorp accepted the information that BCorp gave it. Do you really expect the Semantic Web to educate fools? The issues are whether CCorp has to trust the information it gets from BCorp and whether CCorp can determine whether BCorp is telling the truth. In a situation where information about a URI need not be gathered from ``the standard place'' I don't see any reason why CCorp could not go to ``the standard place'' in ACorp's web site to determine whether the information it is getting from from BCorp follows from the information available from ACorp. I similarly don't see any reason (except for the extremely limited expressive power of RDF) why CCorp could not determine whether BCorp's information is inconsitent with ACorp's information. CCorp is free to do this, or not. All the above is in the most simple case, where one would expect that using information consistently would be most desirable, yet there seems, to me, no requirement that everyone has to use the same authoritative information. There may be a cost to doing something else, but there also may be benefits. For example, suppose ACorp put up pricing information for its widgets? How could anyone sell ACorp's widgets for a different price if everyone had to use ACorp's information about its widgets? Or suppose that ACorp created acorp:invoiceuri3.14159 which has all the right stuff hanging off it to look like a valid invoice saying that ACorp sent 1000 widgets to CCorp for the total price of $2000. If everyone has to believe ACorp about its uris mean/denote then how can CCorp even tell anyone that ACorp is lying? This information will have to use ACorp's URIs and thus will be infected by ACorps lies. Peter F. Patel-Schneider
Received on Friday, 3 October 2003 15:40:31 UTC