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

Sorry for the delay in replying.

On Friday, September 26, 2003, at 10:42  AM, Tim Berners-Lee wrote:

>
> In-Reply-to Bijan's original   
> <http://lists.w3.org/Archives/Public/public-sw-meaning/2003Sep/ 
> 0054.html> , clarifications.
>
> 1.First of all, it does seem a funny question. What can a symbol  
> require of a person?

That would be a funny question. Fortunately, i asked what the *use* of  
certain kind of symbol require, which does elide "what does the  
(correct) use of a URI (in an RDF) require....".

>  Nothing. What can receipt of a message which uses a symbol require of  
> a person? Nothing. You can't require people to do thing by sending  
> them things.

I'll remember that next time I'm subpoenaed .

> We can define a *protocol* in which people do do things, and we can  
> demonstrate
> that if people adhere to the protocol interesting results can be  
> assured.  Then conformance with the protocol would require that one do  
> something.

Hence the question, "What does using a URI (in RDF) require of me and  
my software (to be correct)?", hence the issue of "What does Tim want  
to add to the spec as a requirement on RDF spec compliant software?"

I'm a little astonished that you could read the actual body of my  
message and miss what I was doing.

[snipped stuff that I may come back too]

[About whether one *must* "import" all the ontologies "associated" with  
a URI.]
> Correction: I certainly don't remember saying that you *had* to, and I  
> believe
> I would have argued strongly against me, had I!

Not only did you leave me believing that you endorsed the "had", but  
other people as well. Be that as it may.

You seem to have skipped the key part of my Issue analysis which  
contains an attempt to analyze a key point from your intitial Issue  
raising, to wit.

""""that use of a URI in RDF implies a commitment to its ontology, and  
if
there is doubt as to what ontology that is, the web may be used to
resolve it."""""

I still don't find a reading of this that permits for *less* than a  
MUST and an "import". Perhaps I take commitment too seriously?

>> DanC said, I believe, that all his software already did that.
>>
>> I'm not against software doing that. I'm against the spec requiring  
>> it.
>
> Good.

Uuuuuh, this is what I've been saying since WWW, where it came up. Why  
were you arguing so vehemently with me if you agree?

What in the current specs forbids this? Are you saying you want "MAY"  
language?

There is still something you may want to forbid, which is the use of  
other ontologies which "define" the URI (see the intuition pump). I.e.,  
that an owl:imports of an ontology not endorsed by the URI owner is  
forbidden. (This is the other half of the commitment shoe pair)

Frankly, given all the different things you might pull in, for whatever  
reasons, by whatever techniques, I think it's completely mad to try to  
standardize any of it at the moment. None of these things are forbidden  
by the current specs, to my knowledge, so let's not muddy the waters.

> cwm will operate in a number of modes with respect to looking
> stuff up as a function of the URIs loaded into the knowledge base.
>
>     cwm --closure=flags
>
> where flags are a combination of
>   p - look up predicates
>   s - look up subjects
>   o - look up objects
>   t  - look up the object only where the predicate is rdf:type
>
> An interesting mode is cwm --closure=pt.
> Lets call this "ontological closure".

No. Really, no. To the degree I understand it (which I don't), it  
doesn't seem to be the ontological closure any more than cwm  
--closure=st.

I don't think I get the 't' at all.

> It is a reasonable thing to do, as it adds to the  KB the  
> machine-readable
> information which is assumed shared by the writer and reader of
> a document.

Assumed by whom?

>   If people do this a lot, then it useful to write documents whose
> ontological closure is of a manageable size.  This is the case with any
> real RDF files I've tried. It is what you might expect - people define
> ontologies using ontologies but only to a limited level.
>
> Contrast with   --closure=spo  which pulls in the whole contiguous
> semantic web starting at the given document.  This is not practical.

I'm actually still open :)

> This is interesting, as it highlights a difference between p and s   
> and o
> not only in the spec but in the topology of the web.

I don't see it. I need some examples. Plus, why not --closure='ot'? or  
other variants? i mean, you compared one limited mode with EVERYTHING  
mode and then made assertions about other limited modes. I'm confused.

> But all this about things you *can* do and how we can make that useful.
> It isn't what you *must* do.

And isn't forbidden by the current specs. Excellent. There's nothing  
left to be done.

> (I think actually a lot of interesting work will be in finding  
> combinations
> of breadcrumbs to leave in the ontologies and algorithms for following
> them.   Cwm -- closure=ptr  also follows links to rule files and loads  
> the
> rules. How do we set expectations about the sorts of rules one will
> set and and what will happen if we run them? Can we leave pointers to
> translations to other ontologies?  Can I write a tax form ontology
> so that it points to enough stuff directly or indirectly for an  
> inference
> engine to fill it out? and so on.)

It seems to me that you think you've identified a critically useful  
"closure" principle. But it's not widely deployed, nor is there a lot  
of experience, nor to my knowledge is there a formal account, nor is  
there anything in the current documents that forbid it or even make it  
difficult. So, again, what do you think is missing and why do you think  
we need to put it "in" somewhere?

> 3. PROCEDURAL POINT
>
>> I don't see how this is a matter for Web Architecture rather than the
>> working groups. Not all uses of URIs entail inclusion of the document
>> the URI points to, even in HTML. For example, <a
>> href="...someImage.jpg">...</a> vs. <img src="...soemImage.jpg"/>.
>
> It is an architectural issue in that the meaning/denotation of a URI

How does your closure stuff have anything to do with  
"meaning/denotation"? (Er...meaning and denotation aren't alternative  
terms.)

> is defined in the architecture to be the basically the same for  
> everyone,

"basically"? "the same" always?

> so we have there may be implications on other parts of the web.

Well, if the issue is "what gets included" I stand by my procedural  
point. The connection between meaning and inclusion is tenuous (and I  
don't recall a good clear argument for it, yet, and some movement  
against it), and the connection between denotation and inclusion even  
more so.

> That said, the global hypertext system built out of HTML and
> the global KR system build out of RDF are different in many ways.
> I think we should get the semantic web act together before
> we look at way sin which we try to merge them too closely.
> It might be reasonable to convert/coerce an RDF URI into a hypertext
> anchor of a document describing what the thing is, but it is not
> the primary goal.

Interestingly, I tend to radically disagree, at least in some sense.  
Well, not the last part, but that if there's to be anything distinctive  
about the semantic web qua KR system, its that it brings hypertext  
deeply inside KR (I call this "HyperKrep" :)).

But gosh, I have no idea what it even MEANS. Something about being able  
to follow links, or with using hyperlinks to represent a variety of  
structures. But, really, I don't think we have a clue.

> 4. Retreivability
>
>> Retrievability is a total red herring. Much of Tim's language above
>> seems devoted to weakening the requirement that you look up the
>> ontology each time. That weakening just doesn't do anything for me.
>
> There is no such requirement, so no weakening of it.

So, please supply text that captures your intent by the "use of a URI"  
language quoted above that does *not* produce such a requirement.

>> The
>> requirement is commitment to the URI owner's ontology, and,  
>> apparently,
>> to the current URI owners *current* ontology (which I must try to
>> ascertain to the best of my ability, and we're tolerant of web
>> failures, etc.)
>
> You seem to think that you are being constrained
> as to what you, personally, or you as your software must do.

Well, yes. I read your text and have tried to figure out what you want  
done with such text ("included in some spec", presumably as a normative  
constraint). If you want neither that (or a similar) requirement, nor  
that it be expressed by normative text in some spec, then, uh, what  
*do* you want?

(Thanks to DanC for ferreting out:  
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002May/0126.html)

> You don't have to do anything from the point of view of us defining
> what the RDF means.

Well, your definition of what RDF means might well constrain me, person  
who wants to work with rdf correctly, i.e., correctly wrt its  
semantics, i.e., meaning, and what I can do when working with RDF  
correctly.

I may choose, of course, to work with it incorrectly, or not at all.

>   Whether your machine spends a certain
> amount of time or effort to access things under various circumstances
> depends on what you are trying to do.  If have no goals, turn the
> machine off.

Yes, but I'd like my software to conform to spec. To that end, I'd like  
the specs to specify something useful and achievable. Adding wish lists  
seems pointless. Specifying best practices seems to belong elsewhere.  
Specifying possible practices seems pointless in these specs.

> It is much more a question of defining *if* you do these things, then
> what will you be able to conclude?

Not really. Though there's a bunch that's unclear about that. If I have  
a RDF graph, however achieved, I know what I can (RDFly) conclude  
(based on its logical structure). What I can thereupon do with the  
entailments (or the explicit facts) is a totally different, application  
specific, issue. How could it be otherwise? (i'm sending another  
intuition pump for this)

>   From that may follow your decisions
> as to what to do to achieve a goal.
>
> Yes, to name the class of reasoners which does inference and looks
> up ontological closures as it goes might be useful, just as we have
> various levels of OWL reasoner.  But we don't expect it of everything  
> with
> an RDF parser.

Now I'm really confused. Given the set of behaviors above, it doesn't  
seem too terribly hard to operationalize the various behaviors and to  
write them down and to give them names. If it's useful, why not do it?  
Given the base state is "import nothing", why not expect at least that  
of anything with an RDF parser?

Note: I somewhat despair about formalizing all this.

> 5. Natural language definitions
>
>> Natural language defintions [are a red herring].
>> These are related but distinct. But let me
>> tell you, if you think I'm committed to not only the *formal, machine
>> readable* ontologies (in an importy sense) but the *natural language*
>> ontologies...uh...well, let's just say I don't know how to import the
>> latter. (Actually, this would suggest that I, a software writer, would
>> have to check EVERY URI for the natural language spec and rewrite my
>> software to conform. Yick.)
>
> Only if you want to write software which does more useful things.

Than?

> Yes, people who receive documents written in the OWL ontology

OWL ontology? You mean in the OWL language? There's an awful lot of  
syntax and semantics one has to implement. Little if any of it captured  
in any ontology.

> to derive more useful information have to read the OWL specs
> and stuff. Yick.  Hard work.

And, I believe, somewhat disanalogous from the ordinary use of URIs in  
documents.

>    But you only have o do that
> if you need to.  Maybe you do it because you are claiming to
> provide a service which includes inference as defined in an OWL
> conformance level.

Hmm. I don't disagree with the fact that, given a natural language  
specification of the meaning of some term (probably a collection of  
terms) I, qua software writer, have to implement some code to handle it  
(or just apply existing code, or just my own reactions, in a suitable  
way), but I don't think we're even risen to the level of RDDLesque  
solutions on the Semantic Web.

I'm trying to figure out what I meant by the yick passage...ah, yes. I  
want to suggest that natural language comments can't reasonably be seen  
as constraining the *OWL* (or RDF) meaning of an OWL or RDF document.  
In this, I hearken back to Peter's "Getting the ball rolling" message.  
The whole point of having a *formal* "meaning" is that you can work  
with a narrower aspect of "the meaning" of a sentence (or set of  
sentences). In the first order propositional calculus, *all* I need to  
care about is the (stipulated by truth table) meaning of the  
connectives and the truth values of the atomic sentences. The wonderful  
thing is that I *can* do that...I can do useful things that are  
*sensitive* to the semantics of my sentences, *without* having to care  
about all the details. This is is where we get our joy, right?

By regimenting terms into a formal system, I say of the *defined* terms  
that they have no *futher* meaning than the stipulated one.

I'm no longer sure where I'm going with this.

> 6. Limiting the damage
>
> There is a corner case in which somebody writes
> something rather irrelevant and potentially inconsistent
> in an ontology.  Sally defines Girl as intersection of
> YoungPerson and Female, and also mentions
> that the weather is sunny.
>
> One solution is to say that that is not a friendly way to do things,
> she should not do that.
>
> Another solution is to try to "limit the damage" as you say
> so that somehow the information in the ontology to which
> one is committed is only that which "defines" the predicate
> in question for some value of "defines".  I can't see any
> way to do that formally - only with hand waving.

Yes, this is part of the problem. But absent that weakening, commitment  
to an ontology is commitment to all of it. That commitment seems to  
commit one to something analogous to an import.

> I can see the distinction being used in court but not in a machine.
> So I haven't explored that route.

There's also the question of having "alternate" definitions. And the  
"when" of my commitment (am I commited to the ontology retrievable at  
the time of authorship, or to whatever is retrieved whenever?)

> 7 Naive protocols and safe operating procedures
>
> Actually, the whole question of damage raises another distinction.
> Most of the "intuition pump" example is about things going wrong.

Hmm. I don't quite thing so, though i see where the impression comes  
from. It's about people *disagreeing* and wanting to make their  
disagreement clear. Imagine Molly consciously decides to adopt  
sally:person *with* her redefinition: "You folks have identified a  
concept and then said false things about it".

> I think we may have to consciously distinguish in the design
> of the semantic web in general between the normal expected ways
> of going about things, which we can show will wok, and the
> operating procedures which will allow one to operate safely in
> a potentially hostile environment.

Well, perhaps. Don't these have to be somewhat integrated? Or designed  
in light of each other?

Plus, we seem to be eliding a key point: I'm concerned with the  
intended meaning of the *author of a document*. If molly uses  
sally:person and inside her document, she supplies a definition that's  
contrary to the published sally ontology, and she fails to owl:import  
the sally ontology, I think she probably *intended* to redefine or  
override the sally definition. As I read your "commitment" language,  
the best she can hope for is to have expressed a contradiction.  
Acutally, I don't know what you think she *could* have sensibly  
intended by this. It seems to me that her intent is clear, it's  
discernable by software, and it's not silly or somehow contrary to Web  
architecture. It does have the consequence that use of URIRefs can have  
contextual meaning (or varying meanings), but that's certainly true  
over time, and if true temporally, why not contextually? You may wish  
to *discourage* that, but I just don't see how it's helpful to  
discourage the obviously possible and sometimes useful and often done  
by asserting it's impossible.

> Example: a purchase choice system choses the cheapest product
> which is offered as being compatible with an hp:p314159.
> The naive protocol is for the seller to offer the compatibility and  
> price
> system in the catalogue which you get by dereferencing the
> part URI, and the buyer loading the catalogs into its kb.
> A more secure system filters the catalogs for lies about
> which product is best.  You can define conformance with some
> market protocol in that the catalog only has data of a given form,
> but you still want to be careful about things which break it.

I'm unclear as yet how to connect this back to the earlier discussion.

> Focussing, then, back on what an RDF document means,

Oh whew! The connection is to be made for me! :)

> which
> was the original narrower scope than all of this, I would say we have
> to first define the naive protocol,



> - Use of an HTTP URI as a symbol in an RDF statement
>  refers to one thing which the URI owner intended.

So, this is broken out of the gate, right? I mean, why "intended"? Did  
you mean, "What the current URI owner current intends"? And what if  
they intended it to refer to more than one thing? Why is the one thing  
important, anyway. (I tend to strongly agree with Pat on this. And to  
go further that I'd rather that the use of a URI mean what *I*, the  
document author, intended it to mean.)

> - The URI owner puts true, consistent, hum &/or machine
> readable information in the
>   document that you get should you chose to dereference the URI.

And this seems compatible with "And I assert other things about the  
'one thing' that may or may not be consistent with what the URI owner,  
fool that they may be, sez about it. And I'm taking my 'may' rights  
very seriously and not going to chose to dereference that URI."

> - Nobody hijacks the domain name system, the LAN or the server,
>  or an intervening proxy, or the user's computer, etc

Not even me, document author, with the consent of my document users?

I don't understand how we got from "naive, when everything goes right,  
worry about 'security' later" to this clause.

> If we could get that nailed down first, then afterwards we could  
> launch into
> the questions of what happens when people lie, make mistakes,
> fix mistakes, the net goes down, and so on,

Or the domain name system, server, etc.? I don't understand how the  
"security" problems got sorted.

> as to whether we should
> make the best of it, model everything in an extra level of detail,
> take someone to court or call the to discuss it over lunch, et cetera.
>
> We can also define useful rules of friendly behavior which a community
> could adopt to make a working system within that community.

Cheers,
Bijan.

Received on Friday, 3 October 2003 10:09:11 UTC