RE: New version of URI Declarations [Usage scenarios]

At 7:06 AM +0000 3/5/08, Booth, David (HP Software - Boston) wrote:
>  > From: Pat Hayes [mailto:phayes@ihmc.us]
>>  [ . . . ]
>>  There is a problem (more down-to-earth) with the notion of
>>  'should be accepted', as well. This sounds like its
>>  impossible to enforce,
>
>Correct. It is impossible to enforce because it is impossible to
>know the user's intent. For example, if you use my URI to denote
>the moon in some statements that you publish, there is no way for
>other people's software that reads your statements to distinguish
>between: (a) you chose to accept the assertions; and (b) you did
>not choose to accept the assertions and violated this
>architectural guidance. Therefore, your choice to use my URI to
>denote the moon should be taken as prima facie evidence that you
>agreed with the core assertions in my URI declaration.  If you
>don't, you should use a different URI.

Well, this illustrates the problem, seems to me. Suppose I accept 
your claim that your URI denotes the moon, so that when I use it I am 
also referring to the same moon. But I want to point out that you 
said something false about the moon. Under your proposal, this is 
impossible. I can't say that, because by calling these assertions a 
'declaration', they have been removed from the domain of discussion. 
They have become necessarily attached to that particular URI: so we 
resolve the mistake not by saying (as we should) that your facts are 
wrong, but instead by saying that (since your declared assertions 
can't possibly be wrong) that your URI doesn't in fact denote what 
you say it denotes. Which is why I have to use another URI to denote 
what you said your URI should denote; but then how do you know that 
my URI is intended to denote the same thing as your URI? (Why would I 
coin a new URI if I intend to refer to the same thing?).

In fact, this proposal, ironically, does the exact opposite of what 
you originally said it was for. It is a mechanism which makes it 
impossible to have genuinely referring URIs - we could call them de 
re URIs instead of de dicto URIs - because you have given us a de 
dicto mechanism and called it a de re one.

>
>>  and worse, that there are going to be
>>  cases where it shouldn't be enforced.  Suppose A publishes
>>  some rdf R and says it is a declaration of the URI x:y, and
>>  also says (perhaps using English or a controlled vocabulary)
>>  that x:y is supposed to denote, say, the moon; and suppose
>>  that R says that x:y is made of cheese. Are we supposed to
>>  accept this, just because this twit has called it a
>>  declaration?
>
>No. But if you *choose* to use that URI to denote the moon then
>you are indicating that you *have* accepted the assertions.

WHY?? I know that is your proposal, but it seems to make no sense. 
Why should it be that by using a name correctly, given your 
intentions for using it, that I must therefore agree with everything 
you say about it? This seems to get two different ideas - of 
referring to the same thing, versus agreeing with your propositions - 
mixed up.

>Therefore, if you do not wish to accept the assertions, then you
>should use a different URI when you make statements about the
>moon.

But then we BOTH have the problem of making sure that the other is 
agreeing with our intended referential purposes. You have gone to all 
this trouble to tell me that your URI denotes the moon, and lets 
presume you have succeeded in this task. OK, it denotes the moon: we 
agree. Why the hell should I not then use it to denote the moon while 
talking to you about your claims about the moon?

It seems to me that if we follow your proposal to its logical 
conclusion, that all differences of fact will be transformed to 
differences of reference. You coin a URI to refer to the moon and 
make an assertion about the moon which is false. I am obliged to 
conclude that your URI does not in fact denote the moon, in spite of 
your claims. (It denotes some imaginary moonie-ish thing that you 
claim exists and satisfies your assertions.) So I coin a new URI to 
denote the real moon, and use to tell you about your mistake: but you 
think I'm wrong, so your conclusion is that my URI doesn't really 
denote the actual moon but must denote yet some third imaginary thing 
that satisfies all my assertions. At this point we are in a worse 
state of mutual confusion that we would be if we simply disagreed 
about the moon.

>You could even mint your own URI based on the subset of my
>URI's assertions that you do choose to accept,

And what relationship would its denotation bear to the denotation of 
your URI, in this case?

>  in a manner
>comparable to the URI substitution technique described here:
>http://dbooth.org/2007/splitting/#urisub
>
>>
>>      These assertions are intended to delimit the range of
>>      possible interpretations of what the denoted resource might
>>      be -- ideally uniquely determining the resource, but (a)
>>      that depends on the quality of the assertions, and (b) as
>>      you pointed out, ultimately there is no way to ensure that
>>      a user's actual interpretation is the same as the minter's
>>      intent.
>>
>>  Right, so the 'ideally' here isn't even an ideal: its
>>  impossible.
>
>Yes and no.  I completely agree that it is impossible in
>general, as you've aptly pointed out over the past couple
>of years.  But for a given application, it may well be
>adequate in uniquely determining the resource.

I remain sceptical. Show me ONE example of how this might be 
achieved, without using an appeal to some commonly accepted 
referential vocabulary.

>  Thus,
>someone publishing a URI declaration should strive to
>make their assertions uniquely determine the resource
>as best they can for the range of applications that they
>anticipate, realizing that it is not possible to make
>one that will be uniquely determining for all applications.

But now we are back in a familiar situation where publication of SWeb 
content has to be made in some kind of 'closed' world of particular 
applications. And also, this gives every publisher of a new URI a 
huge and ill-defined task to strive to do. Strive is right, by the 
way:

make great efforts to achieve or obtain something;
struggle or fight vigorously.

>
>>    SCENARIO 1: Fred wishes to publish some RDF assertions
>>    about a particular protein. He notices that Alice, Beatrice and
>>    Carl have already published assertions about the protein, and
>>    they all use the same URI to denote that
>>    protein: the URI minted by Alice. Fred notices that if he
>>    uses Alice's URI to denote the protein, his assertions will be
>>    logically inconsistent with some of Alice's assertions,
>>    although they are logically consistent with Beatrice and Carl's
>>    assertions. He wonders whether he should publish his assertions
>>    using Alice's URI -- and post a blog entry noting that his
>>    assertions should not be used in conjunction with Alice's
>>    assertions -- or mint a new URI.
>>
>>    Question: Should Fred use Alice's URI?
>>
>>    Answer: No.  He should mint a new URI and indicate the
>>    relationship (not owl:sameAs) to Alice's URI -- at least
>>    rdfs:seeAlso.
>>
>>  Whoa. I think this is crazy. The scenario says that the URI
>>  denotes the protein, so lets accept that it indeed does.  (The
>>  'attachment' to the particular protein may be done for example
>>  by relating the URI to a standardized protein database accepted
>>  by the community.) If this is so, then the only way that Fred
>>  and Alice can be inconsistent is if they actually disagree
>>  about the facts of the matter.  Perhaps Fred has a more
>>  up-to-date value for the molecular weight than Alice had, or
>>  something. But in this case, I think Fred should use the same
>>  URI to refer to the protein. Removing the inconsistency by
>>  using a different name is like saying: Oh, I guess we must be
>>  talking about different proteins, then. But they aren't, right?
>>  They are talking about the same thing, but they disagree on the
>>  facts. This is a case where some published RDF is *wrong*, and
>>  should be corrected: or at least, the real disagreement should
>>  be resolved.
>
>The problem with Fred using Alice's URI is that there is no
>way in general to distinguish between: (a) Fred attempting to talk
>about a different resource than Alice was talking about; and (b)
>one of them being wrong.

Indeed, there isn't, and your proposal doesn't help; in fact, it 
makes things worse. Two different URIs can denote the same thing or 
different things. Whereas one URI must denote a unique thing in each 
model, so at least our arguments about it can be cast into a 
framework of arriving at a state of mutual consistency. By using the 
same URI we are, in effect, agreeing that we are talking about the 
same thing or things, no matter how vague we might both be about what 
exactly this or these actually are.

>
>>From an architectural perspective, there is no objective notion
>of right or wrong: some assertions are merely useful to some
>applications, while others are useful to other applications. Even
>assertions that you and I might think of as "wrong" may be
>adequate and useful for any applications. For example, highway
>mapping assertions that presume the earth is flat may be
>perfectly adequate for many guidance applications.

Sure. Though this is a dangerous line of argument to follow too far: 
it leads to the 'rejoice in ambiguity' line I tried to sell a while 
back, which didn't meet with a very eager audience :-)

>
>>  [ . . . ]
>>    SCENARIO 3: Erin has accumulated some observations
>>    about a different protein, and she wishes to publish them as
>>    assertions. Some of them are merely assertions that serve to
>>    uniquely identify the protein that she wishes to talk about.
>>    Others are observations about the protein's behavior.
>>
>>
>>  Its not obvious that this distinction makes sense. Or at any
>>  rate, its not obvious that there is a particular category of
>>  facts that serve only to pin down reference.
>
>I agree that there may be no way in general to distinguish
>between assertions that serve to identify something and
>other assertions.  This is why the "core assertions" in a URI
>declaration are, by fiat, viewed as identifying assertions.

There is no way to tell male from female chicks. So we will put a red 
mark on some of them and say that the ones with a red mark are male, 
by fiat. Seems like a poor strategy to me.

>
>>
>>    She is very confident about the correctness of the
>>    first set of assertions, but no so confident about the
>>    assertions about the protein's behavior. She mints a URI
>>    http://example/erin/proteins#p4 for the protein and wonders
>>    whether she should publish all of her assertions in one OWL
>  >   document at http://example/erin/proteins, or separate them
>>    into two documents.
>>
>>    Question: Should Erin put all of these assertions in
>>    a single document?
>>
>>    Answer: No.  Erin should separate them into two documents.
>>
>>
>>  Well, I agree that is good practice, but because she is more
>>  confident about some than about others. Thats the reason for
>>  the distinction, not that some pin down reference and others
>>  are mere facts.
>  >
>>  YOu have assumed that the reference-nailing assertions are
>>  also the ones that are known with confidence, but that begs
>  > an important question.
>
>Yes, I made that simplifying assumption in this scenario.
>
>>  Consider a case where some empirical
>>  results are available which are very confidently true, but
>>  its not clear which protein they are relevant to (perhaps
>>  they were extracted from a biopsy which may have mixed two
>>  kinds of tissue: if this were genes instead of proteins, and we are
>>  talking about cancer typing, this is a real problem.) Now
>>  what do we 'declare' ?
>
>You can declare a URI for the substance that was observed: a
>potetial mix of two kinds of tissue.

You could, but its unlikely to be a useful strategy. It amounts to 
saying that because there is a likelihood of experimental error, we 
should treat each observation as a separate experiment, and that 
eliminates the error.

Pat


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
http://www.ihmc.us/users/phayes      phayesAT-SIGNihmc.us
http://www.flickr.com/pathayes/collections