Re: Proposed issue: What does using an URI require of me and my software?

On Thursday, October 9, 2003, at 07:52 AM, John Black wrote:

>> From: Peter F. Patel-Schneider [mailto:pfps@research.bell-labs.com]
>> Sent: Friday, October 03, 2003 3:40 PM
>>
>> From: "John Black" <JohnBlack@deltek.com>
>> Subject: RE: Proposed issue: What does using an URI require
>>
>>>> -----Original Message-----
>>>> From: pat hayes [mailto:phayes@ihmc.us]
>>>> Sent: Friday, October 03, 2003 1:48 PM
>>>> To: LYNN,JAMES (HP-USA,ex1)
>>
>> [...]
>>
>>>> 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.

Ok. We do have mechanisms for handling Fraud. I don't see that extra 
machinery is needed at the moment. (Or rather, *What* that extra 
machinery is.) IIRC, the worry Tim raised was that without addition 
specs, companies could do that *and then* claim it *wasn't* fraud. That 
seems unlikely from your example.

>>>   Those URIs belong to ACorp and it was never
>>> ACorps intention that acorp:uri123 be called anything other
>>> than a acorp:StandardWidget.

Well, we need to be more precise. If the Widget were damaged or 
"refurbished" you might want to call it a :RefurbStandardWidget, or if 
you enhanced it you might ....

It does seem clear that they didn't want to call it an 
acorp:DeluxeWidget.

>>>  How could ACorp make this
>>> clear to CCorp?  One solution would be to publish at
>>> acorp:uri123 the statement, this is <> a acorp:StandardWidget.

Sure. I'm not sure why ACorp is quite in the loop. How does CCorp 1) 
make sure it doesn't get ripped off, 2) document and get remedy for the 
fraud. The former requires some sort of verification of BCorp's claims 
(and if ACorp colludes with BCorp, relying solely on ACorp seems 
unwise). No one is against that, but current Semantic Web specs offer 
nothing, and can't really offer anything in the near term (other than 
VERY foundational support, in the sense of giving unambiguous syntax 
and semantics, etc.). I mean, you could also have a "trusted verifyier" 
that watchdogs BOTH A and B corp,and you only purchase when you've 
gotten their go ahead. The latter seems already there. "Look, in this 
signed document, BCorp claim that they were acorp:DeluxeWidgets...they 
weren't."

What more (concretely) is needed? Needed *now*? Needed now and we can 
usefully specify within the scope of any current or near term working 
group?

>>> Note that this is a boring, trivial example.  There is no
>>> inference, semantic search, or other sw-interesting ideas
>>> in it.

Presumably it does have some sw-interesting ideas *in some sense* (in 
that people think that "web of trust" and other supposed sw stuff will 
*help* with these problems), but I fail to see that this is any 
different than with xml or html or human documents, and I *really* fail 
to see what we can say in an e.g., rdf doc that would at all help. 
Except maybe "caveat reasoner".

>>>  I'm using it to point out that URIs have
>>> social meanings that will become represented and
>>> communicated by the Semantic Web.

I so don't understand that sentence, and have little hope of connecting 
it back to your example. So in so far as your were using your example 
to "point out" the rest of the sentence, it failed for me.

>> 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?
>
> Somehow these "fools" always turn out to be our brothers and sisters,
> mothers and fathers, sons and daughters, friends and family - even me.
> Automobile manufacturers were finally required to provide seatbelts
> and airbags to protect the "fools" that drive recklessly and to
> protect us from them.  I suspect they objected at first, saying things
> like "Its not cars that cause accidents, its the fools who drive them
> carelessly that kill people.  You'll cripple transportation if you ask
> us to get involved in these problems."

Uh...I don't by this analogy. The main point is that there is *already* 
extensive practices for dealing with fraud and lying. They may not be 
great, but they're there. In so far that the semantic web *doesn't* 
alter the picture, we should be careful about how we either paint the 
problems or try to solve them.

One might argue that the semantic web will permit radically new forms 
or scale of fraud or damage from it. But you need a way more powerful 
argument than your trivial example and a weak analogy.

But this suggests that you'll be *vehemently* against Tim's "naive 
protocol" and only prefer "robust" ones.

> There's another argument made that considerations of such
> problems and any solutions to them don't belong in the architecture.
> In the past, buildings were designed without regard for earthquakes.
> Over the years, thousands of people died.  Now building architects
> build defenses against earthquakes into the architecture from the
> start.

The analogies have well leaked over to the hysterical. One key part of 
disanalogy is that with earthquake resistent design, there developed an 
*understanding* of how to do it. Where's our understanding? Do we build 
earthquake proof buildings in non earthquake likely spots? Are we 
needing to protect agaisnt *earthquakes* or fire? Or flood? Or bombs? 
Is *architecture* the right place to deal with this (or building codes? 
or fire detectors).

> Its also suggested that we don't know enough about what the Semantic
> Web will become to act now.  I thought of this argument this morning
> as I was driving to work in an intense fog that comes over Northern
> Virginia sometimes.  When my visibility is reduced, and I can't see
> what dangers lie ahead, I tend to become more cautious and alert,
> rather than less.  So why does the uncertainty of direction of the
> Semantic Web argue for doing nothing?

At this point I become totally annoyed by the analogies. This is no 
longer argument, and the analogies stretch all credibility.

However, there's several arguments made in this line. One is that it's 
too early for *specification*, or rather *standardization* (write all 
the specs you want). That is, we should let practice and experience 
determine what further standardization we want. We think that the 
current specs don't *block* any or many useful outcomes and perhaps 
encourage them. Some solutions (many?) are *specific* to the shape of 
how people *actually* use the web. So we *are* being cautious. We're 
trying not to break what happens. So see, your analogy supports the 
view you invoked it against.

>  Are we hoping that if we
> just keep quiet and leave it up to government and lawyers, maybe
> they won't come back and ask us, "Hey.  Can't you do something
> technological about this? something like quake-proof buildings
> or automobiles with airbags?"

It would be nice to *know* what those things were. I mean, I *DON'T* 
have a clue of how to rid the web of fraud, lies, or even how to make 
it automatically detectable. It's more like, "It'd be great if these 
things were safer...hit the labs and come up with something. Oh, by the 
way, the automated chainsaws to cut through the doors have a tendency 
to lop of limbs. That wasn't a good idea."

> There seems to be a sense in society that the makers of products
> should think about these things.  Is the Semantic Web different?

It's not a product.

>  Are
> sw-agents products?  I

Many will be. But look at how crappy consumer protection if for 
software...you expect us to do better? In a couple of months (or 
years)? With pure techonological solutions?

> f not, what are they?  Are they beings, endowed
> by their creators with inalienable rights? Do they have first amendment
> rights?  Someone's going to think and act on these questions.  Why not
> us, here, now?

Gosh, I hope not this last set. Frankly, they are entirely out of scope 
of this list, I think.

Cheers,
Bijan.

Received on Thursday, 9 October 2003 08:29:31 UTC