W3C home > Mailing lists > Public > public-sw-meaning@w3.org > May 2004

Re: Comment on "Named Graphs, Provenance and Trust"

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 11 May 2004 12:22:25 -0500
Message-Id: <p06001f51bcc6a6d6e0c7@[]>
To: Bijan Parsia <bparsia@isr.umd.edu>
Cc: public-sw-meaning@w3.org, "John Black" <JohnBlack@deltek.com>

>On May 6, 2004, at 3:11 PM, Pat Hayes wrote:
>>>This is what I previously referred to as a 'stipulative definition' or
>>>'stipulative ontology'.  What I am trying to get at intuitively is the
>>>ability to say, "When this term is used in this context it SHALL be
>>>interpreted to mean that".  And as a crude example of its use, imagine
>>>I had need to import two ontologies, one a universal business language
>>>ontology of commercial transactions, and the other, Bijan and Peter's
>>>alternative ontology of transactions, both of which contained some terms
>>>I needed but which had an incompatible "invoice" term that caused an
>>>ambiguity (inconsistency).  Now I want to be able to eliminate the
>>>ambiguity by stating that within this named graph, when the term
>>>"invoice" is used, it SHALL be interpreted according to the UBL ontology
>>>(or vice versa).
>(The above was from John Black.) Interestingly, John, this is 
>exactly the kind of scenario we were interesting in making possible, 
>even though the current tools (owl:imports, cut and paste, etc.) are 
>a bit crude. The current canonical way to achieve this is to simply 
>only include in your document the desired axioms. On some views 
>(e.g., some variant's of Tim's view), it was much more difficult to 
>exclude the URI owner's axioms.

I don't think that interpretation was ever Tim's intended meaning 
(I.e. the interpretation in which importing the URI owner's axioms 
was kind of obligatory). You only get to that from what Tim was (I 
think) talking about by imposing a very limited view of what 
'meaning' means.

>However, as pat point out, you can't stop me (currently, or really, 
>ever) from adding yet more axioms to your set.

Wait a minute. Look, a SET is a mathematical abstraction. It doesnt 
make sense to speak of DOING something to a set. What you can add 
axioms to is a document or an ontology or some concrete thing on the 
Web somewhere. So lets talk about those. I CAN stop you adding axioms 
to MY document, and of course you can write documents of your own out 
the wazoo, and can incorporate my axioms into them (by reference or 
by cutting and pasting) and I can't do anything about that.  All that 
is obvious.

>E.g., if I import *your* document, I'm almost surely going to add 
>assertions, and I'm free to add axioms, even concerning your classes.

Right, of course (does this ever need to be said again??) but YOU are 
saying those axioms, (in YOUR document), right? John isn't asserting 
them. So take a hypothetical third party, call him Joe, who can read 
all this stuff. If Joe reads what Bijan publishes he will get a 
potentially different idea than the one he would get if he only reads 
what John publishes. Of course: so what? Does that change the meaning 
of what John published? No. Does it change the meaning of John's 
terms as used by Bijan? Seems to me it's up to Joe to decide that. If 
Joe believes Bijan as well as John, then the meaning of the terms is 
determined by (Bijan's ontology + John's ontology) as far as Joe is 
concerned. What if John protests that his terminology is being 
misused by Bijan. Well, he may be right. Still, Joe can reply: OK, 
but I'm not only hearing you, I'm also hearing Bijan. Suppose John 
admits that there's no way that he, John, can stop Joe listening to 
Bijan, but still wants to restrict the meanings of his terms *as 
intended by him* to be only the meaning that can be inferred from 
his, John's, publication. That is about the best that he can do, 
seems to me, and that is what our proposal allows him to do. It would 
enable Joe, if he were so inclined, to discover that Bijan was using 
John's terms in ways that violate John's intentions, and so (if he, 
Joe, were so inclined) to follow John's intentions more accurately: 
it allows Joe to resist the infection by Bijan of alien meaning into 
Joe's understanding of John's vocabulary: again, all assuming that 
Joe is interested more in what John says than in what Bijan says.

However, all that said, it seems to me that what might be called the 
normal case is one where everyone is kind of in broad agreement about 
intended meanings, and everyone acknowledges that in a case of a 
clash of meaning or intention, that the 'owner' or originator of a 
URI has more social authority over the intended meaning than any 
other single authority. There will be exceptions, eg if an entire 
community 'misuses' a term in some way consistently, but such 
phenomena are familiar already and we know, broadly , how to handle 

>Even if I just add facts ("instances"), I can affect the *inferred* 
>axioms (e.g., the classification). So the question becomes, how far 
>reaching should your stipulations reach?
>I *like* being able to say, of my documents, that the axioms are 
>*these* ones I put in some effort to put in, and not *those* which I 
>put in some effort to exclude.
>>But the performative story only gives you a kind of act, not a 
>>stipulation about other's acts or interpretations. So let me try to 
>>rephrase this a little: suppose we say that the intuitive force of 
>>such a stipulative definition is to declare that *your intention* 
>>is that the terms shall have the meaning you give to them, and that 
>>any usage (such as Bijan and Peter's, in the example) which clashes 
>>or is incompatible with your meanings is not intended by you. This 
>>of course does not *prevent* P & B from misusing your terminology 
>>(how could it?) , or force anyone else to believe you rather than 
>>them (so all this foolish
>Foolish stupid? Foolish tactically unwise? Foolish cute?

Foolish stupid, since you put it that way. I think y'all are 
misunderstanding the point.

Take the http GET protocol. This sets out detailed instructions about 
exactly what must be done by browsers, network software and servers 
when you click on a hyperlink in a Web page. This stuff is intensely 
proscriptive: so does the HTTP spec oppressively limit the freedom of 
software to act as it chooses? Is this tyranny in action? Well, if 
you like, you could say that, but this would be a foolish conclusion. 
In fact, it is false: I *could* write a browser which claimed its 
right to treat hyperlinks differently, cast off the oppressive chains 
of the HTTP protocol and act in its own proud individualistic way. It 
would just be a useless browser, of course, rather in the way that 
human being who insisted on not believing anything told to it would 
be a useless human being (we all know some of these, right?) and a 
SWeb agent which refused to draw conclusions from any ontologies 
except those directly indicated would be useless. The point is not 
that any of these things are OBLIGED by some external tyrannical 
compulsion to conform to any social convention, so much as the 
observation that if they don't conform then they aren't going to be 
able to work very effectively, particularly if everyone else is 
conforming: which is the entire point of having the conventions in 
the first place. If you approach any social system of communication 
with a basically paranoid assumption that everyone is out to screw 
you, and with the prime goal of avoiding infection by other's ideas 
and meanings, then you are likely to not be able to communicate as 
effectively as an agent which approaches communication with the 
intention of communicating. You and Peter are adopting a stance of 
what might be called semantic paranoia as a basic operating 
assumption of the SWeb, which seems to me to get the entire thing 

>>analogizing with tyranny, oppression and freedom is beside the point)
>I dispute that it's (necessarily) a misuse, so perhaps the analogy, 
>about which I was having a few qualms, is apt.
>The point of this discussion is how much de jure authority we are 
>giving to URI owners.

None whatsoever, in the sense that you seem to be understanding 
'authority'. No amount of web publication in any medium obliges any 
reader to endorse, utilize or agree with any of it if they choose not 
to: and this goes for software as much as it does for human agents. 
This is just obvious. (So if someone seems to be saying something 
that contradicts this, maybe you should contemplate the possibility 
that you may have misunderstood what they were really saying.)

>On some of the views that Peter and I opposed, the only sanctioned 
>way to avoid slurping in the URI owner's URIs was to use only your 
>own URIs.  Perhaps we're all past that now, but at the time such 
>views were seriously expoused and argued for.

I don't think they ever were. But let us assume that we are all past 
that now, indeed.

>I actually don't *know* what the right default is, but I'm pretty 
>sure that a link/transclusion distinction is useful wrt to URIs in 
>RDF and OWL documents, just as it is useful in HTML pages.

Useful, yes. No argument there.

>Looking at HTML, I tend to go with linking being the default.

What does that mean, exactly? (Ie the 'default' part)

>Given that it seems quite possible that the most interesting sets of 
>axioms concerning a resource might *not* be published by the URI 
>owner, I'm not convinced that transclusion (rather than keying to 
>other aggregated sources) is the most useful mechanism. Pervasive 
>transclusion just seems to be nuts. Pervasive, uspecified 
>transclusion (oh, this agent could do SOC and this one might now, 
>but who knows, it depends) is an interoperability problem.

Seems to me that on your view, the evolution of human language could 
be described as an interoperability problem (Hey, those other apes 
are TELLING  me stuff. But s**t, how I do I know they aren't lying? I 
never had THAT problem before.  Maybe I'd be better off without a 
left temporal lobe...)

>owl:imports gives us some sort of discipline for transclusions.
>As for forcing vs. non forcing, either our standards mean something 
>and we want to be able to mobilize arguments for this or that 
>behavior based on standards compliance, or we should pack up and 
>take a nice vacation.

See above riff on HTTP. I think you just have a mistaken view of the 
entire standards business. Nobody forces anyone to conform to a 
standard: but IF YOU WANT TO COMMUNICATE, then the standard provides 
for a way for everyone to be on the same wavelength. If you don't 
want to communicate, then OK, indeed, take a vacation.

>People who are irked at OWL-DL or OWL-Full features can, in fact, 
>write software that processes OWL ontologies in non-compliant ways,

And they already are doing, in fact.

>  but there are a lot of social pressures not to do so.

I think the reality is that the social pressures will determine the 
actual uses that the technology is put to, and that the best we can 
do as standard-setters is to attempt to guess this as well as we can. 
But the pressure we can exert is like throwing a tennis ball into a 
gale. Once we let it go, the wind will take it where its going to go, 
and the best we can hope to do is come along afterwards and try to 
understand what happened.

>Furthermore, there is and has been a lot of talk, much of it loose, 
>of making/supporting various laws

The courts will decide things about the internet and no doubt 
eventually about SW content, but we techies really, really do not 
have any control over that, for sure.

>  regarding semantic web content. (At these points, I remember: 
>http://www.xml.com/pub/a/2001/01/31/politics.html. I should nag 
>kendall about that. I suspect there's a good deal of update to be 
>I had more but this is coming late enough as it is (curse grading 
>and all its works).

Hey, you have to pay some kind of tax. I have to write reports to the Army.

IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Tuesday, 11 May 2004 13:24:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:02 UTC