Splitting vs. Interpreting

[Sean B. Palmer]

You write about ambiguous and specific references here:

http://dbooth.org/2007/splitting/

When I worked on EARL in 2002, we had to solve httpRange-14, and we
did it in a practical way which your splitting document reminds me of.

We might want to evaluate a tool of some kind in EARL, say the W3C
Validator. But then we didn't know whether validator.w3.org was the
tool itself or a page about the tool. That's httpRange-14 in a
nutshell, before it was “solved” with the 303 hack.

So what we did was this:

<http://validator.w3.org/> earl:tool _:Validator .

The clever bit is that the earl:tool property says: if the subject is
a Document (i.e. an IR), then the object is the Tool described by that
document; whereas if the subject is a Tool, then the object is simply
the same thing as the subject.

And as you can imagine, this is extensible to interpreting ambiguous
resources in all kinds of ways. Now the TAG finding says that it's
removed a certain level of ambiguity, but there are other ambiguities
one might want to resolve when a page 303s and then still doesn't
define carefully what's at the end of it. So the EARL method is much
more practical.

You might also want to think a bit harder about statements such as
“there is no architectural need for Person and IR to be considered
disjoint”. Consider if you were using Facebook and it started
conflating people with groups and games and so on. But of course
people break the rules of the web until they matter, and since there's
no Semantic Web User Agent this rule doesn't matter.

I'm not saying that the TAG finding should be canned because you can
use the kind of interpretation properties that I've described as a way
around it. The point is rendered moot by various architectural
problems. But you ought to compare the 2002 and 2009 architectural
solutions carefully.

--
Sean B. Palmer, http://inamidst.com/sbp/

[Sean B. Palmer]

Sorry, looks like I had an old address on file for you.

---------- Forwarded message ----------
From: Sean B. Palmer <sean@...>
Date: Tue, Jun 16, 2009 at 8:23 PM
Subject: Splitting vs. Interpreting
To: David Booth <dbooth@...>
Cc: www-tag@...

You write about ambiguous and specific references here:

http://dbooth.org/2007/splitting/

When I worked on EARL in 2002, we had to solve httpRange-14, and we
did it in a practical way which your splitting document reminds me of.

We might want to evaluate a tool of some kind in EARL, say the W3C
Validator. But then we didn't know whether validator.w3.org was the
tool itself or a page about the tool. That's httpRange-14 in a
nutshell, before it was “solved” with the 303 hack.

So what we did was this:

<http://validator.w3.org/> earl:tool _:Validator .

The clever bit is that the earl:tool property says: if the subject is
a Document (i.e. an IR), then the object is the Tool described by that
document; whereas if the subject is a Tool, then the object is simply
the same thing as the subject.

And as you can imagine, this is extensible to interpreting ambiguous
resources in all kinds of ways. Now the TAG finding says that it's
removed a certain level of ambiguity, but there are other ambiguities
one might want to resolve when a page 303s and then still doesn't
define carefully what's at the end of it. So the EARL method is much
more practical.

You might also want to think a bit harder about statements such as
“there is no architectural need for Person and IR to be considered
disjoint”. Consider if you were using Facebook and it started
conflating people with groups and games and so on. But of course
people break the rules of the web until they matter, and since there's
no Semantic Web User Agent this rule doesn't matter.

I'm not saying that the TAG finding should be canned because you can
use the kind of interpretation properties that I've described as a way
around it. The point is rendered moot by various architectural
problems. But you ought to compare the 2002 and 2009 architectural
solutions carefully.

--
Sean B. Palmer, http://inamidst.com/sbp/

[Pat Hayes]

On Jun 16, 2009, at 2:24 PM, Sean B. Palmer wrote:

> Sorry, looks like I had an old address on file for you.
>
> ---------- Forwarded message ----------
> From: Sean B. Palmer <sean@...>
> Date: Tue, Jun 16, 2009 at 8:23 PM
> Subject: Splitting vs. Interpreting
> To: David Booth <dbooth@...>
> Cc: www-tag@...
>
> You write about ambiguous and specific references here:
>
> http://dbooth.org/2007/splitting/
>
> When I worked on EARL in 2002, we had to solve httpRange-14, and we
> did it in a practical way which your splitting document reminds me of.
>
> We might want to evaluate a tool of some kind in EARL, say the W3C
> Validator. But then we didn't know whether validator.w3.org was the
> tool itself or a page about the tool. That's httpRange-14 in a
> nutshell, before it was “solved” with the 303 hack.
>
> So what we did was this:
>
> <http://validator.w3.org/> earl:tool _:Validator .
>
> The clever bit is that the earl:tool property says: if the subject is
> a Document (i.e. an IR), then the object is the Tool described by that
> document; whereas if the subject is a Tool, then the object is simply
> the same thing as the subject.

This is almost exactly the technique I suggested for use in  
bioinformatics, where people want to point to both documents about  
proteins and identifiers of actual proteins, and not worry too much  
about the distinction when they say 'sameAs'. The (crude but workable)  
suggestion was to use a special sameProteinAs property which is sameAs  
when its value is a protein but something like IsADocumentAbout when  
its value is a document. And yes, this obviously generalizes to other  
categories, and indeed one could imagine a generic sameKindOfThingAs  
which has subproperties identified by an isAbout link to a class name  
(all this in RDFS or one of the fuller OWLS, of course).

Pat Hayes

>
> And as you can imagine, this is extensible to interpreting ambiguous
> resources in all kinds of ways. Now the TAG finding says that it's
> removed a certain level of ambiguity, but there are other ambiguities
> one might want to resolve when a page 303s and then still doesn't
> define carefully what's at the end of it. So the EARL method is much
> more practical.
>
> You might also want to think a bit harder about statements such as
> “there is no architectural need for Person and IR to be considered
> disjoint”. Consider if you were using Facebook and it started
> conflating people with groups and games and so on. But of course
> people break the rules of the web until they matter, and since there's
> no Semantic Web User Agent this rule doesn't matter.
>
> I'm not saying that the TAG finding should be canned because you can
> use the kind of interpretation properties that I've described as a way
> around it. The point is rendered moot by various architectural
> problems. But you ought to compare the 2002 and 2009 architectural
> solutions carefully.
>
> --
> Sean B. Palmer, http://inamidst.com/sbp/
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[David Booth-6]

Hi Sean,

Thanks for your comments and observations.  Responses are below.

On Tue, 2009-06-16 at 20:24 +0100, Sean B. Palmer wrote:

> Sorry, looks like I had an old address on file for you.
>
> ---------- Forwarded message ----------
> From: Sean B. Palmer <sean@...>
> Date: Tue, Jun 16, 2009 at 8:23 PM
> Subject: Splitting vs. Interpreting
> To: David Booth <dbooth@...>
> Cc: www-tag@...
>
> You write about ambiguous and specific references here:
>
> http://dbooth.org/2007/splitting/
>
> When I worked on EARL in 2002, we had to solve httpRange-14, and we
> did it in a practical way which your splitting document reminds me of.
>
> We might want to evaluate a tool of some kind in EARL, say the W3C
> Validator. But then we didn't know whether validator.w3.org was the
> tool itself or a page about the tool. That's httpRange-14 in a
> nutshell, before it was “solved” with the 303 hack.
>
> So what we did was this:
>
> <http://validator.w3.org/> earl:tool _:Validator .
>
> The clever bit is that the earl:tool property says: if the subject is
> a Document (i.e. an IR), then the object is the Tool described by that
> document; whereas if the subject is a Tool, then the object is simply
> the same thing as the subject.
>
> And as you can imagine, this is extensible to interpreting ambiguous
> resources in all kinds of ways. Now the TAG finding says that it's
> removed a certain level of ambiguity, but there are other ambiguities
> one might want to resolve when a page 303s and then still doesn't
> define carefully what's at the end of it. So the EARL method is much
> more practical.

Yes, that's one way to side-step the ambiguity issue.  But I want to
point out that it is actually *avoiding* the ambiguity issue rather than
addressing it.  In your example above, there is no tool/document
ambiguity.  The reason is that the same URI is never used to *directly*
denote both a tool and a web page, even though the domain of earl:tool
is the union of Tools and Documnets.  If a particular URI denotes a
Document, then it always denotes a document, but the earl:tool property
uses that document to indirectly identify a tool.

>
> You might also want to think a bit harder about statements such as
> “there is no architectural need for Person and IR to be considered
> disjoint”.

It occurs to me that I may not have been clear that I was referring to
web architecture as a whole -- not to the architecture of a specific
application.  Some specific applications may indeed need to treat Person
as disjoint from IR; others may not.  And for web architecture as a
whole, there is no architectural need to take a position about whether
or not they are disjoint.

> Consider if you were using Facebook and it started
> conflating people with groups and games and so on. But of course
> people break the rules of the web until they matter, and since there's
> no Semantic Web User Agent this rule doesn't matter.

The key observation behind that statement is that ambiguity depends on
application: what is clear enough to one application may be ambiguous to
a different application that needs finer distinctions.  The choice of
how finely to define a resource is an engineering trade-off.  There is a
cost involved in defining a resource very finely.  Actually, there are
two kinds of cost involved.  One is the extra burden of writing and
processing the additional constraints required to define it very finely.
But the other is that the more finely a resource is defined -- the more
constraints that are imposed on it -- the less flexible it is for reuse.
On the other hand, if the definition is too loose then it may be too
ambiguous for many applications.  For example, if Facebook needs to
distinguish between people and games then it obviously won't work very
well to have a URI that conflates the two.  But this is not an issue.
It is a matter of one application making engineering choices that are
not appropriate for another application.

One may politely ask: "please distinguish between resources and tools,
because *my* application and many others need this distinction".  But
the fact is that there are also many applications that do *not* need
this distinction.  So although one might politely ask, I don't think we
can blame those who decline such a request.

>
> I'm not saying that the TAG finding should be canned because you can
> use the kind of interpretation properties that I've described as a way
> around it. The point is rendered moot by various architectural
> problems. But you ought to compare the 2002 and 2009 architectural
> solutions carefully.

I'm not suggesting that the httpRange-14 decision should be canned
either.  I actually *agree* with it.  The flaw that I think should be
fixed is the definition of "information resource" (IR) in the AWWW:
http://www.w3.org/TR/webarch/#id-resources
"all of their essential characteristics can be conveyed in a message".
There are two aspects of that definition that I think are flawed:

1. The text (later on) suggests that the class of IRs is disjoint with
the class of people: "cars and dogs . . . are not information
resources".  As I explained above, there is no architectural need for
this constraint.  Furthermore, trying to define the boundary of exactly
what is and what is *not* an IR is problematic, as the many discussions
around this question have illustrated. For these reasons I think this
constraint should be eliminated.

2. When considering IRs that are based on CGI scripts, I don't think
"all of their essential characteristics can be conveyed in a message" is
quite right criterion.  What matters architecturally is that IRs can
have "representations" (in the AWWW sense).  In HTTP, this means that an
IR can emit a 200 response.  That's what matters architecturally.  And
the reason it matters architecturally is that there are a number of
specifications and protocols that suddenly come into play if a resource
can have "representations": mime types, character encodings, content
negotiation, etc.


--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Alan Ruttenberg-2]

(apologies for the resend, Sean - missed the cc's in the first response)

On Tue, Jun 16, 2009 at 3:23 PM, Sean B. Palmer <sean@...> wrote:

You write about ambiguous and specific references here:

http://dbooth.org/2007/splitting/

When I worked on EARL in 2002, we had to solve httpRange-14, and we
did it in a practical way which your splitting document reminds me of.

We might want to evaluate a tool of some kind in EARL, say the W3C
Validator. But then we didn't know whether validator.w3.org was the
tool itself or a page about the tool. That's httpRange-14 in a
nutshell, before it was “solved” with the 303 hack.

So what we did was this:

<http://validator.w3.org/> earl:tool _:Validator .

The clever bit is that the earl:tool property says: if the subject is
a Document (i.e. an IR), then the object is the Tool described by that
document; whereas if the subject is a Tool, then the object is simply
the same thing as the subject.

This isn't quite the same idea as splitting (which is more problematic). Here the ambiguity is maintained due to not completely constraining the interpretation of http://validator.w3.org/. Essentially, you are asserting, as a consequence of the use of earl:tool, that http://validator.w3.org/ is of type unionOf(tool document). However, assuming that tool and document are disjoint, you can't use http://validator.w3.org/ both in one place which forces it to be of type document (e.g as the target of foaf:page), and another which forces it to be a tool (e.g. http://validator.w3.org/ :runUnderOS :linux). Doing so would lead to a logical consistency.

Dave's splitting proposal, OTOH, lands up recapitulating the class/instance distinction with another mechanism, one which doesn't offer the same support for reasoning that that the existing SW stack offers.

What I like about your solution is that you at least admit that documents and services are different sorts of things, instead of using a term inconsistently. If *everyone* used http://validator.w3.org/ in this way, it could work.

But if everyone is to use the same scheme, it would seem better to me to define a new type that made directly clear the nature of http://validator.w3.org/ as being a sort of service which can do two different things a) respond with a report about conformance to RDF syntax of a supplied document and b) respond with a page that documents how (a) works. Then have two *unambiguous* properties a) earl:tool that relates http://validator.w3.org/ to an entity whose type is tool, and b) foaf:page that relates to a document. It would be helpful to document, as well, that the tool (b) generates a new instance of document, each time it is "run".

-Alan

 

And as you can imagine, this is extensible to interpreting ambiguous
resources in all kinds of ways. Now the TAG finding says that it's
removed a certain level of ambiguity, but there are other ambiguities
one might want to resolve when a page 303s and then still doesn't
define carefully what's at the end of it. So the EARL method is much
more practical.

You might also want to think a bit harder about statements such as
“there is no architectural need for Person and IR to be considered
disjoint”. Consider if you were using Facebook and it started
conflating people with groups and games and so on. But of course
people break the rules of the web until they matter, and since there's
no Semantic Web User Agent this rule doesn't matter.

I'm not saying that the TAG finding should be canned because you can
use the kind of interpretation properties that I've described as a way
around it. The point is rendered moot by various architectural
problems. But you ought to compare the 2002 and 2009 architectural
solutions carefully.

--
Sean B. Palmer, http://inamidst.com/sbp/

[Xiaoshu Wang]

Sean B. Palmer wrote:

> Sorry, looks like I had an old address on file for you.
>
> ---------- Forwarded message ----------
> From: Sean B. Palmer <sean@...>
> Date: Tue, Jun 16, 2009 at 8:23 PM
> Subject: Splitting vs. Interpreting
> To: David Booth <dbooth@...>
> Cc: www-tag@...
>
> You write about ambiguous and specific references here:
>
> http://dbooth.org/2007/splitting/
>
> When I worked on EARL in 2002, we had to solve httpRange-14, and we
> did it in a practical way which your splitting document reminds me of.
>
> We might want to evaluate a tool of some kind in EARL, say the W3C
> Validator. But then we didn't know whether validator.w3.org was the
> tool itself or a page about the tool. That's httpRange-14 in a
> nutshell, before it was “solved” with the 303 hack.
>
> So what we did was this:
>
> <http://validator.w3.org/> earl:tool _:Validator .
>
> The clever bit is that the earl:tool property says: if the subject is
> a Document (i.e. an IR), then the object is the Tool described by that
> document; whereas if the subject is a Tool, then the object is simply
> the same thing as the subject.
>  

The solution is cleaver only because it pushes the ball to someone
else.  But it does not solve any problem at all.  Whoever is to deploy
the resource is still burdened with the impossible question: is what
s/he is about to deploy is a Document or not because she needs the
answer to know if s/he should 200 or 303.  Or she needs  

The real issue is that TAG, for whatever reason that I cannot
understand, refuses to acknowledge such a simple truth:  what you get
from a URI is NOT what a URI denotes.

We never know what a URI denotes -- it is our purpose to share that
knowledge.  But the sharing is achieve from sharing what we get from the
URI.

*Document* is what we get from a URI but *resource* is not.  I have
argued this in the past as well as in the upcoming paper at IR-KR2009
(http://ir-kr.okkam.org/workshop-program/ir-kr-ijcai-09-program).

Once we understand the above distinction.  The remedy is simple.  We
need to solve it *syntactically* by using a URI convention to denote
what is we get from a URI, which I have proposed in another  manuscript
to ISWC 2009 (which fate I don't know).

Xiaoshu

> And as you can imagine, this is extensible to interpreting ambiguous
> resources in all kinds of ways. Now the TAG finding says that it's
> removed a certain level of ambiguity, but there are other ambiguities
> one might want to resolve when a page 303s and then still doesn't
> define carefully what's at the end of it. So the EARL method is much
> more practical.
>
> You might also want to think a bit harder about statements such as
> “there is no architectural need for Person and IR to be considered
> disjoint”. Consider if you were using Facebook and it started
> conflating people with groups and games and so on. But of course
> people break the rules of the web until they matter, and since there's
> no Semantic Web User Agent this rule doesn't matter.
>
> I'm not saying that the TAG finding should be canned because you can
> use the kind of interpretation properties that I've described as a way
> around it. The point is rendered moot by various architectural
> problems. But you ought to compare the 2002 and 2009 architectural
> solutions carefully.
>
>  

[Williams, Stuart (HP Labs, Bristol)]

Xaioshu,

> The real issue is that TAG, for whatever reason that I cannot
> understand, refuses to acknowledge such a simple truth:  what you get
> from a URI is NOT what a URI denotes.

Please will you stop making this claim.  You and I have visited this many times [and (no-doubt) bored many people on this list] and agreed that no-one[*] on the TAG holds the view that "what you get from a URI is what a URI denotes". You again start your argument by restating a false-premise, that the TAG holds a position that AFAICT it never held whilst I was a part of it.

Stuart
--
[*] by which I mean that I know of no-one on the TAG that holds the view which you imply.

[Xiaoshu Wang]

Williams, Stuart (HP Labs, Bristol) wrote:

> Xaioshu,
>
>  
>> The real issue is that TAG, for whatever reason that I cannot
>> understand, refuses to acknowledge such a simple truth:  what you get
>> from a URI is NOT what a URI denotes.
>>    
>
> Please will you stop making this claim.  You and I have visited this many times [and (no-doubt) bored many people on this list] and agreed that no-one[*] on the TAG holds the view that "what you get from a URI is what a URI denotes". You again start your argument by restating a false-premise, that the TAG holds a position that AFAICT it never held whilst I was a part of it.
>
> Stuart
> --
> [*] by which I mean that I know of no-one on the TAG that holds the view which you imply.
>  

I am not implying everyone but I do imply someone because, otherwise, I
just could not understand: what is the hold up for even an open debate?

I have to file a serious complain in order to get my manuscript accepted
to the IR-KR2009, which I am glad the PC chairs did.  One reviewer, whom
I was told is a very "well known person" to the web community that they
must respect, made some very unfair (as far as from I can understand)
comments.  My impression is that the reviewer just simply did not want
my opinion to be out there.

This makes me very upset because something must be *seriously* wrong.  
Here is what I wrote to the PC chairs of IR-KR2009, I think the problem
should concern us all.

"I remember Bertrand Russell explained the difference between Religion
and Philosophy.  He said they both differ from science because they are
all about speculations.  But the former appeals to authority and the
latter to human reason.  There are some unhealthy trend in the Web and
it becomes more religious than philosophical -- this really concerns
us.  One of the purpose of this article is trying to make it right.  Not
that my opinion is right, this is minor but what is important is to
evaluate alternative opinion through intelligent debate but by
obedience.  It really surprises me that one person has so much power and
can control even a workshop.

Honestly, I am not simply disappointed.  I am actually quite angry and
seriously concerned -- not for my own sake but for the sake of the Web
community.  Hopefully, we will not turn the Web philosophy into a Web
religion."


Xiaoshu

[Pat Hayes]

On Jun 18, 2009, at 9:36 AM, Xiaoshu Wang wrote:

Sean B. Palmer wrote:

Sorry, looks like I had an old address on file for you.

---------- Forwarded message ----------

From: Sean B. Palmer <sean@...>

Date: Tue, Jun 16, 2009 at 8:23 PM

Subject: Splitting vs. Interpreting

To: David Booth <dbooth@...>

Cc: www-tag@...

You write about ambiguous and specific references here:

http://dbooth.org/2007/splitting/

When I worked on EARL in 2002, we had to solve httpRange-14, and we

did it in a practical way which your splitting document reminds me of.

We might want to evaluate a tool of some kind in EARL, say the W3C

Validator. But then we didn't know whether validator.w3.org was the

tool itself or a page about the tool. That's httpRange-14 in a

nutshell, before it was “solved” with the 303 hack.

So what we did was this:

<http://validator.w3.org/> earl:tool _:Validator .

The clever bit is that the earl:tool property says: if the subject is

a Document (i.e. an IR), then the object is the Tool described by that

document; whereas if the subject is a Tool, then the object is simply

the same thing as the subject.

 

The solution is cleaver only because it pushes the ball to someone else.  But it does not solve any problem at all.  Whoever is to deploy the resource is still burdened with the impossible question: is what s/he is about to deploy is a Document or not because she needs the answer to know if s/he should 200 or 303.  Or she needs  
The real issue is that TAG, for whatever reason that I cannot understand, refuses to acknowledge such a simple truth:  what you get from a URI is NOT what a URI denotes.

But why not? Seems to me that the absoluteness of your negative judgement here is just as wrong as the naive positive judgement. The very power of descriptive logics arises from their being topic-neutral: they can describe, their names can refer to, anything at all. And I see no reason to *exclude* 'what you get from a URI' from that universe of possible referents. 

We never know what a URI denotes -- it is our purpose to share that knowledge.  But the sharing is achieve from sharing what we get from the URI.

I agree the two roles are distinct, but one and the same thing might be both the shared thing and the topic of the content represented in that shared thing. And in this case, we *can* know what the URi denotes. In fact, this is how referents are attached to things in daily life, by explicit ostention. I pass you a book, and I say "read this, you will enjoy it". My referential word "this" is attached to the actual book by the causal nexus of my utterance being linked to the act of passing the actual book. What http-range-14 says is just like this, in a Web setting. If you toss a URI at me and I pass you back a 200-coded reply, I am in effect saying "This entity involved in the this transaction, here and now, is what you are asking about; it is the thing that the name you just used refers to".

Pat

*Document* is what we get from a URI but *resource* is not.  I have argued this in the past as well as in the upcoming paper at IR-KR2009 (http://ir-kr.okkam.org/workshop-program/ir-kr-ijcai-09-program).

Once we understand the above distinction.  The remedy is simple.  We need to solve it *syntactically* by using a URI convention to denote what is we get from a URI, which I have proposed in another  manuscript to ISWC 2009 (which fate I don't know).

Xiaoshu

And as you can imagine, this is extensible to interpreting ambiguous

resources in all kinds of ways. Now the TAG finding says that it's

removed a certain level of ambiguity, but there are other ambiguities

one might want to resolve when a page 303s and then still doesn't

define carefully what's at the end of it. So the EARL method is much

more practical.

You might also want to think a bit harder about statements such as

“there is no architectural need for Person and IR to be considered

disjoint”. Consider if you were using Facebook and it started

conflating people with groups and games and so on. But of course

people break the rules of the web until they matter, and since there's

no Semantic Web User Agent this rule doesn't matter.

I'm not saying that the TAG finding should be canned because you can

use the kind of interpretation properties that I've described as a way

around it. The point is rendered moot by various architectural

problems. But you ought to compare the 2002 and 2009 architectural

solutions carefully.

 

------------------------------------------------------------

IHMC                                     [phone] or [phone]   

40 South Alcaniz St.           [phone]   office

Pensacola                            [phone]   fax

FL 32502                              [phone]   mobile

phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Williams, Stuart (HP Labs, Bristol)]

Xiasho,

> -----Original Message-----
> From: Xiaoshu Wang [mailto:wangxiao@...]
> Sent: 18 June 2009 16:31
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: Sean B. Palmer; david@...; www-tag@...
> Subject: Re: Fwd: Splitting vs. Interpreting
>
> Williams, Stuart (HP Labs, Bristol) wrote:
> > Xaioshu,
> >
> >  
> >> The real issue is that TAG, for whatever reason that I cannot
> >> understand, refuses to acknowledge such a simple truth:  what you get
> >> from a URI is NOT what a URI denotes.
> >>    
> >
> > Please will you stop making this claim.  You and I have
> > visited this many times [and (no-doubt) bored many people on
> > this list] and agreed that no-one[*] on the TAG holds the
> > view that "what you get from a URI is what a URI denotes".
> > You again start your argument by restating a false-premise,
> > that the TAG holds a position that AFAICT it never held
> > whilst I was a part of it.
> >
> > Stuart
> > --
> > [*] by which I mean that I know of no-one on the TAG that
> > holds the view which you imply.
> >  
> I am not implying everyone but I do imply someone because, otherwise, I
> just could not understand: what is the hold up for even an
> open debate?

Well... http://www.w3.org/TR/webarch is pretty clear in its one and only diagram that what is obtained from the web are awww:representation of a resource as opposed to the resource itself. I think that accords with your position.

> I have to file a serious complain in order to get my manuscript accepted
> to the IR-KR2009, which I am glad the PC chairs did.  One reviewer, whom
> I was told is a very "well known person" to the web community that they
> must respect, made some very unfair (as far as from I can understand)
> comments.  My impression is that the reviewer just simply did not want
> my opinion to be out there.

I can make no comment. However, FWIW as was not involved in the review process at all.

> This makes me very upset because something must be *seriously* wrong.  
> Here is what I wrote to the PC chairs of IR-KR2009, I think the problem
> should concern us all.
>
> "I remember Bertrand Russell explained the difference between Religion
> and Philosophy.  He said they both differ from science because they are
> all about speculations.  But the former appeals to authority and the
> latter to human reason.  There are some unhealthy trend in the Web and
> it becomes more religious than philosophical -- this really concerns
> us.  One of the purpose of this article is trying to make it right.  Not
> that my opinion is right, this is minor but what is important is to
> evaluate alternative opinion through intelligent debate but by
> obedience.  It really surprises me that one person has so much power and
> can control even a workshop.
>
> Honestly, I am not simply disappointed.  I am actually quite angry and
> seriously concerned -- not for my own sake but for the sake of the Web
> community.  Hopefully, we will not turn the Web philosophy into a Web
> religion."

Fair enough... but you cannot make a valid argument by attributing a position to a group that it does not hold (and AFAIK never has).

> Xiaoshu

Stuart
--

[Xiaoshu Wang]

Pat Hayes wrote:

>
> On Jun 18, 2009, at 9:36 AM, Xiaoshu Wang wrote:
>
>> Sean B. Palmer wrote:
>>> Sorry, looks like I had an old address on file for you.
>>>
>>> ---------- Forwarded message ----------
>>> From: Sean B. Palmer <sean@... <mailto:sean@...>>
>>> Date: Tue, Jun 16, 2009 at 8:23 PM
>>> Subject: Splitting vs. Interpreting
>>> To: David Booth <dbooth@... <mailto:dbooth@...>>
>>> Cc: www-tag@... <mailto:www-tag@...>
>>>
>>> You write about ambiguous and specific references here:
>>>
>>> http://dbooth.org/2007/splitting/
>>>
>>> When I worked on EARL in 2002, we had to solve httpRange-14, and we
>>> did it in a practical way which your splitting document reminds me of.
>>>
>>> We might want to evaluate a tool of some kind in EARL, say the W3C
>>> Validator. But then we didn't know whether validator.w3.org was the
>>> tool itself or a page about the tool. That's httpRange-14 in a
>>> nutshell, before it was “solved” with the 303 hack.
>>>
>>> So what we did was this:
>>>
>>> <http://validator.w3.org/> earl:tool _:Validator .
>>>
>>> The clever bit is that the earl:tool property says: if the subject is
>>> a Document (i.e. an IR), then the object is the Tool described by that
>>> document; whereas if the subject is a Tool, then the object is simply
>>> the same thing as the subject.
>>>  
>> The solution is cleaver only because it pushes the ball to someone
>> else.  But it does not solve any problem at all.  Whoever is to
>> deploy the resource is still burdened with the impossible question:
>> is what s/he is about to deploy is a Document or not because she
>> needs the answer to know if s/he should 200 or 303.  Or she needs  
>> The real issue is that TAG, for whatever reason that I cannot
>> understand, refuses to acknowledge such a simple truth:  what you get
>> from a URI is NOT what a URI denotes.
>
> But why not? Seems to me that the absoluteness of your negative
> judgement here is just as wrong as the naive positive judgement. The
> very power of descriptive logics arises from their being
> topic-neutral: they can describe, their names can refer to, anything
> at all. And I see no reason to *exclude* 'what you get from a URI'
> from that universe of possible referents.

What I am saying is: they are different, individually but not
universally. This is the problem -- I think the core of all
philosophical and logic argument -- the distinction between individuals
and universals.

Universally, you can do anything you want with a your URI.  But you
*define* it to be that way, not because there is something
*intrinsically* different in that way.  This is the gist, as far as I
can understand, what makes Wittgeinstein to say that "meaning is use".  
The use of a symbol, which a URI is, is defined a priori to make a
distinction but not assigned to some a priori distinction.

We can, for instance, define the term "document" to denote a thing that
has no mass, as Stuart once suggested, that is fine because it has an
*object* criteria so the *definition* is pragmatic.  But to think in the
reverse, i.e., to find something intrinsic to a thing which we can call
them document is *always* a waste of time.  Try to find any, I do mean
*any*, concept, and see if you can find a clear definition.  You don't
because there is always an exception.  That is what Russel tried to
suggest -- to avoid build class so to avoid contradiction.  But then
there is still a Russell's paradox.

>
>> We never know what a URI denotes -- it is our purpose to share that
>> knowledge.  But the sharing is achieve from sharing what we get from
>> the URI.
>
> I agree the two roles are distinct, but one and the same thing might
> be both the shared thing and the topic of the content represented in
> that shared thing. And in this case, we *can* know what the URi denotes.
No.  We always communicate through symbols.  They never share.
> In fact, this is how referents are attached to things in daily life,
> by explicit ostention. I pass you a book, and I say "read this, you
> will enjoy it". My referential word "this" is attached to the actual
> book by the causal nexus of my utterance being linked to the act of
> passing the actual book.
Sure, this only establish the relationship between "this" and the
"book".  It says nothing about what "the book" means to you or to me.  
In this case, what you meant "this" is the content of the book but not
the physical signals, such as light or the mass, that transmitted to me,
right? So, what is the "this" that you are passing me?
> What http-range-14 says is just like this, in a Web setting. If you
> toss a URI at me and I pass you back a 200-coded reply, I am in effect
> saying "/This/ entity involved in the this transaction, here and now,
> is what you are asking about; it is the thing that the name you just
> used refers to".
This is my point: what is the actual entity that is involved in the
transaction?  Is it the byte-stream that you received or what the URI
denote?

Xiaoshu

>
> Pat
>
>> *Document* is what we get from a URI but *resource* is not.  I have
>> argued this in the past as well as in the upcoming paper at IR-KR2009
>> (http://ir-kr.okkam.org/workshop-program/ir-kr-ijcai-09-program).
>>
>> Once we understand the above distinction.  The remedy is simple.  We
>> need to solve it *syntactically* by using a URI convention to denote
>> what is we get from a URI, which I have proposed in another
>>  manuscript to ISWC 2009 (which fate I don't know).
>>
>> Xiaoshu
>>
>>> And as you can imagine, this is extensible to interpreting ambiguous
>>> resources in all kinds of ways. Now the TAG finding says that it's
>>> removed a certain level of ambiguity, but there are other ambiguities
>>> one might want to resolve when a page 303s and then still doesn't
>>> define carefully what's at the end of it. So the EARL method is much
>>> more practical.
>>>
>>> You might also want to think a bit harder about statements such as
>>> “there is no architectural need for Person and IR to be considered
>>> disjoint”. Consider if you were using Facebook and it started
>>> conflating people with groups and games and so on. But of course
>>> people break the rules of the web until they matter, and since there's
>>> no Semantic Web User Agent this rule doesn't matter.
>>>
>>> I'm not saying that the TAG finding should be canned because you can
>>> use the kind of interpretation properties that I've described as a way
>>> around it. The point is rendered moot by various architectural
>>> problems. But you ought to compare the 2002 and 2009 architectural
>>> solutions carefully.
>>>
>>>  
>>
>>
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     [phone] or [phone]  
> 40 South Alcaniz St.           [phone]   office
> Pensacola                            [phone]   fax
> FL 32502                              [phone]   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>

[Sean B. Palmer]

On Thu, Jun 18, 2009 at 12:46 PM, Alan Ruttenberg wrote:

> you are asserting, as a consequence of the use of earl:tool, that
> http://validator.w3.org/ is of type unionOf(tool document).

Well what I gave was just a colloquial description, but even so I
didn't say what the case would be if the subject were neither Tool nor
Document.

To really get it to work, you'd presumably need to use a literal
anyway, so the model would be a bit different. And there may be other
considerations.

Remember too that this solution was devised before the TAG finding.

--
Sean B. Palmer, http://inamidst.com/sbp/

[Sean B. Palmer]

On Thu, Jun 18, 2009 at 7:45 AM, David Booth wrote:

> The flaw that I think should be fixed is the definition of "information
> resource" (IR) in the AWWW:
> http://www.w3.org/TR/webarch/#id-resources
> "all of their essential characteristics can be conveyed in a message".

What would you propose for an erratum?

--
Sean B. Palmer, http://inamidst.com/sbp/

[Sean B. Palmer]

On Thu, Jun 18, 2009 at 4:57 PM, Williams, Stuart (HP Labs, Bristol) wrote:

> Well... http://www.w3.org/TR/webarch is pretty clear in its one and only
> diagram that what is obtained from the web are awww:representation of
> a resource as opposed to the resource itself.

But it doesn't say that representation and resource are disjoint.

You could make a URI that denotes “the first representation obtained
per RFC 2616 from this URI”, and as far as I know that would be
consistent with AWWW. Of course it would be very peculiar.

(You might want to consider whether it would need to return a 303.)

--
Sean B. Palmer, http://inamidst.com/sbp/

[Pat Hayes]

On Jun 18, 2009, at 10:57 AM, Williams, Stuart (HP Labs, Bristol) wrote:

> Xiasho,
>
>> -----Original Message-----
>> From: Xiaoshu Wang [mailto:wangxiao@...]
>> Sent: 18 June 2009 16:31
>> To: Williams, Stuart (HP Labs, Bristol)
>> Cc: Sean B. Palmer; david@...; www-tag@...
>> Subject: Re: Fwd: Splitting vs. Interpreting
>>
>> Williams, Stuart (HP Labs, Bristol) wrote:
>>> Xaioshu,
>>>
>>>
>>>> The real issue is that TAG, for whatever reason that I cannot
>>>> understand, refuses to acknowledge such a simple truth:  what you  
>>>> get
>>>> from a URI is NOT what a URI denotes.
>>>>
>>>
>>> Please will you stop making this claim.  You and I have
>>> visited this many times [and (no-doubt) bored many people on
>>> this list] and agreed that no-one[*] on the TAG holds the
>>> view that "what you get from a URI is what a URI denotes".
>>> You again start your argument by restating a false-premise,
>>> that the TAG holds a position that AFAICT it never held
>>> whilst I was a part of it.
>>>
>>> Stuart
>>> --
>>> [*] by which I mean that I know of no-one on the TAG that
>>> holds the view which you imply.
>>>
>> I am not implying everyone but I do imply someone because,  
>> otherwise, I
>> just could not understand: what is the hold up for even an
>> open debate?
>
> Well... http://www.w3.org/TR/webarch is pretty clear in its one and  
> only diagram that what is obtained from the web are  
> awww:representation of a resource as opposed to the resource itself.  
> I think that accords with your position.

I think possibly there may be a misunderstanding here about the  
meaning of the phrase "obtained from". If I walk up to the Web, so to  
speak, and throw a URI at it, then what I get back is (as Stuart says)  
a representation of something. But what I managed to make contact  
with, and what sent me that representation, and which that  
representation is a(n awww:)representation of, is supposed to be a  
resource of some (special) kind. And Ive been reading Xaioshu as  
meaning that that resource, whatever it is, is what is "obtained from"  
the Web; in which case, his position makes more sense (though I still  
don't agree with it :-)

Pat

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Williams, Stuart (HP Labs, Bristol)]

Hello Sean,

> -----Original Message-----
> From: sean.b.palmer@...
> [mailto:sean.b.palmer@...] On Behalf Of Sean B. Palmer
> Sent: 18 June 2009 17:41
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: Xiaoshu Wang; david@...; www-tag@...
> Subject: Re: Fwd: Splitting vs. Interpreting
>
> On Thu, Jun 18, 2009 at 4:57 PM, Williams, Stuart (HP Labs,
> Bristol) wrote:
>
> > Well... http://www.w3.org/TR/webarch is pretty clear in its one and only
> > diagram that what is obtained from the web are awww:representation of
> > a resource as opposed to the resource itself.
>
> But it doesn't say that representation and resource are disjoint.
>
> You could make a URI that denotes "the first representation obtained
> per RFC 2616 from this URI", and as far as I know that would be
> consistent with AWWW. Of course it would be very peculiar.

Yes... but would that be the same URI as the one that was used to obtain that first representation? I don't think so.
Also would representations of resource 'denoted' by that URI be byte wise identical to the original representation?

I was trying to respond to Pat's final para:

<quote>
        I agree the two roles are distinct, but one and the same thing might be
        both the shared thing and the topic of the content represented in that
        shared thing. And in this case, we *can* know what the URi denotes. In
        fact, this is how referents are attached to things in daily life, by explicit
        ostention. I pass you a book, and I say "read this, you will enjoy it".
        My referential word "this" is attached to the actual book by the causal
        nexus of my utterance being linked to the act of passing the actual book.
        What http-range-14 says is just like this, in a Web setting. If you toss a
        URI at me and I pass you back a 200-coded reply, I am in effect saying
        "This entity involved in the this transaction, here and now, is what you
        are asking about; it is the thing that the name you just used refers to".
</quote>

I was/am inclined to object a little, suggesting what is in fact being said by the 200-reply is:

        "This entity involved in the this transaction, here and now, is a representation of you
        are asking about; it conveys a view of the thing that the name you just used refers to".

But I've also tried to take Pat's 'saying' as written and wonder then about the consequences.

        Either:
        - that the referent can change with time. (which of course is possible with un-cool URIs anyway).
        ie. the association of the name with the particular entity is only of the moment.

        Or
        - that the referent is an immutable resource with a single invariant representation (type rather than token[*])
          which is literally the resource.

Of course Pat might also tell me that what he, as the user of the name, was referring to is quite different from whatever I might have 'baptised' with the name - and that nothing can prevent the same name being used to refer to different things in different usages.

[*] webarch is not clear about whether representations are 'types' that categorise sets of messages (events with temporal/spatial/network extent) or the individual messages themselves, 'tokens', which although byte equivalent occupy a different extent.

> (You might want to consider whether it would need to return a 303.)

:-)

>
> --
> Sean B. Palmer, http://inamidst.com/sbp/
>

Stuart
--

[Sean B. Palmer]

(Whoops, hit reply instead of reply-to-all.)

---------- Forwarded message ----------
From: Sean B. Palmer <sean@...>
Date: Thu, Jun 18, 2009 at 6:28 PM
Subject: Re: Fwd: Splitting vs. Interpreting
To: "Williams, Stuart (HP Labs, Bristol)" <skw@...>

On Thu, Jun 18, 2009 at 6:16 PM, Williams, Stuart (HP Labs, Bristol) wrote:

> Yes... but would that be the same URI as the one that was used to
> obtain that first representation? I don't think so.

I'm not sure what you're asking, but I suspect you don't believe that
a URI can denote something that doesn't exist at the time of creating
the URI. But there are weirder URIs than that:

file:///Users/sbp/example.txt

What does that one identify?

So yes, an HTTP URI that identifies the first representation
dereferenced from it is extremely peculiar. But it is possible, and
you can come up with other peculiar things.

> Also would representations of resource 'denoted' by that URI be byte
> wise identical to the original representation?

No, they need not be. As AWWW says:

‘A representation is data that encodes information about resource
state. Representations do not necessarily describe the resource, or
portray a likeness of the resource, or represent the resource in other
senses of the word "represent".’

--
Sean B. Palmer, http://inamidst.com/sbp/

[Williams, Stuart (HP Labs, Bristol)]

> >
> > Well... http://www.w3.org/TR/webarch is pretty clear in its one and  
> > only diagram that what is obtained from the web are  
> > awww:representation of a resource as opposed to the resource itself.  
> > I think that accords with your position.
>
> I think possibly there may be a misunderstanding here about the  
> meaning of the phrase "obtained from". If I walk up to the Web, so to  
> speak, and throw a URI at it, then what I get back is (as Stuart says)  
> a representation of something.

So far so good...

> But what I managed to make contact  
> with, and what sent me that representation, and which that  
> representation is a(n awww:)representation of, is supposed to be a  
> resource of some (special) kind.

Still ok...
"(special)" alluding to 'so-called' "information resource"?

And parenthetically because of controversy over 1) objective charactterisation of such a 'special' kind of resources and 2) whether robust characterisation is actually necssary or possible?

> And Ive been reading Xaioshu as  meaning that that resource, whatever
> it is, is what is "obtained from" the Web; in which case, his position
> makes more sense (though I still  don't agree with it :-)

FWIW my reading of Xiaoshu's is that he complains that the TAG holds the position that it takes what is "obtained from" the web (aka. an awww:representation) as being *the* referenced resource, and that that is not a position that the TAG should hold - which is fortunate (maybe) because AFAIK it is not infact a position held by the TAG (or by TR/webarch).

That the awww:representation obtained could be *a* resource is possible. However, the obtained representation is just not (usually, ever?) the resource being referred to in the original reference.

I'm still thinking about your book example... particularly

        "This entity involved in the this transaction, here and now, is what you are asking
        about; it is the thing that the name you just used refers to".

The physical book seems to serve as both message (awww:representation) and resource. The closest 'electronic' example I can get to is an immutable file/document that has a single invariant representation over its entire lifetime.

FWIW: I think Xiaoshu, you, I and the TAG (at least the one I was part of) hold(held) very similar positions.

> Pat
>
> ------------------------------------------------------------
> IHMC                                     [phone] or
> [phone]
> 40 South Alcaniz St.           [phone]   office
> Pensacola                            [phone]   fax
> FL 32502                              [phone]   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Stuart
--

[Pat Hayes]

On Jun 18, 2009, at 12:53 PM, Williams, Stuart (HP Labs, Bristol) wrote:

>
>>>
>>> Well... http://www.w3.org/TR/webarch is pretty clear in its one and
>>> only diagram that what is obtained from the web are
>>> awww:representation of a resource as opposed to the resource itself.
>>> I think that accords with your position.
>>
>> I think possibly there may be a misunderstanding here about the
>> meaning of the phrase "obtained from". If I walk up to the Web, so to
>> speak, and throw a URI at it, then what I get back is (as Stuart  
>> says)
>> a representation of something.
>
> So far so good...
>
>> But what I managed to make contact
>> with, and what sent me that representation, and which that
>> representation is a(n awww:)representation of, is supposed to be a
>> resource of some (special) kind.
>
> Still ok...
> "(special)" alluding to 'so-called' "information resource"?

Yes

>
> And parenthetically because of controversy over 1) objective  
> charactterisation of such a 'special' kind of resources and 2)  
> whether robust characterisation is actually necssary or possible?

Yes

>
>> And Ive been reading Xaioshu as  meaning that that resource, whatever
>> it is, is what is "obtained from" the Web; in which case, his  
>> position
>> makes more sense (though I still  don't agree with it :-)
>
> FWIW my reading of Xiaoshu's is that he complains that the TAG holds  
> the position that it takes what is "obtained from" the web (aka. an  
> awww:representation) as being *the* referenced resource

Oh. That is clearly wrong.

> , and that that is not a position that the TAG should hold - which  
> is fortunate (maybe) because AFAIK it is not infact a position held  
> by the TAG (or by TR/webarch).

Quite.

>
> That the awww:representation obtained could be *a* resource is  
> possible.

Even that is rather problematic. In spite of my espousal of the  
ubiquity of logic, the transient awww:representations themselves seem  
to be a rare example of a thing that it is very difficult, close to  
impossible, to refer to.

> However, the obtained representation is just not (usually, ever?)  
> the resource being referred to in the original reference.

Right.

>
> I'm still thinking about your book example... particularly
>
> "This entity involved in the this transaction, here and now, is  
> what you are asking
> about; it is the thing that the name you just used refers to".
>
> The physical book seems to serve as both message  
> (awww:representation) and resource.

Right, the example could be better, I see that it is misleading for  
this reason. Try this. I point to a cloud in the sky and say to you  
"look at that". And because of the proximity of my utterance and the  
physical setting and my gesture and your understanding of such  
gestures, it is clear that my word "that" refers to the actual,  
particular, cloud. Here, the 'message' (awww:representation) is  
probably the light coming from the cloud to your retina, or some such.

As I understand Xiaoshu's recent reply, one could object that there is  
no way to guarantee conclusively that the thing you are identifying in  
the actual world is indeed the thing, or aspect, which I had in mind  
when I uttered the word. This is similar to Quine's point about the  
ultimate impossibility of translation: "gavagai" uttered in the  
vicinity of rabbits  might mean rabbit, or it might mean that the  
quality of rabbitness is locally manifested: it depends on your, er,  
ontology. I guess I just don't buy this argument, because it (the  
argument) seems to entail that none of us could ever learn a language:  
but we do. But lets take that debate offline. My point was only that  
the http-range-14 ruling is very much like what happens in everyday  
life when we attach names to their referents by using a word in close  
proximity to the referent in certain linguistically recognizable ways.  
Which I myself find kind of satisfying, but maybe thats just me. :-)

Pat

> The closest 'electronic' example I can get to is an immutable file/
> document that has a single invariant representation over its entire  
> lifetime.
>
> FWIW: I think Xiaoshu, you, I and the TAG (at least the one I was  
> part of) hold(held) very similar positions.
>
>> Pat
>>
>> ------------------------------------------------------------
>> IHMC                                     [phone] or
>> [phone]
>> 40 South Alcaniz St.           [phone]   office
>> Pensacola                            [phone]   fax
>> FL 32502                              [phone]   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
> Stuart
> --
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[David Booth-6]

On Thu, 2009-06-18 at 08:53 -0400, Alan Ruttenberg wrote:

> From: Alan Ruttenberg <alanruttenberg@...>
> (apologies for the resend, Sean - missed the cc's in the first response)
>
> On Tue, Jun 16, 2009 at 3:23 PM, Sean B. Palmer <sean@...> wrote:
> >
> > You write about ambiguous and specific references here:
> >
> > http://dbooth.org/2007/splitting/
> >
> > When I worked on EARL in 2002, we had to solve httpRange-14, and we
> > did it in a practical way which your splitting document reminds me of.
> >
> > We might want to evaluate a tool of some kind in EARL, say the W3C
> > Validator. But then we didn't know whether validator.w3.org was the
> > tool itself or a page about the tool. That's httpRange-14 in a
> > nutshell, before it was “solved” with the 303 hack.
> >
> > So what we did was this:
> >
> > <http://validator.w3.org/> earl:tool _:Validator .
> >
> > The clever bit is that the earl:tool property says: if the subject is
> > a Document (i.e. an IR), then the object is the Tool described by that
> > document; whereas if the subject is a Tool, then the object is simply
> > the same thing as the subject.
>
> This isn't quite the same idea as splitting (which is more
> problematic). Here the ambiguity is maintained due to not completely
> constraining the interpretation of http://validator.w3.org/.
> Essentially, you are asserting, as a consequence of the use of
> earl:tool, that http://validator.w3.org/ is of type unionOf(tool
> document). However, assuming that tool and document are disjoint, you
> can't use http://validator.w3.org/ both in one place which forces it
> to be of type document (e.g as the target of foaf:page), and another
> which forces it to be a tool (e.g. http://validator.w3.org/
> :runUnderOS :linux). Doing so would lead to a logical consistency.
> Dave's splitting proposal, OTOH, lands up recapitulating the
> class/instance distinction with another mechanism, one which doesn't
> offer the same support for reasoning that that the existing SW stack
> offers.
> What I like about your solution is that you at least admit that
> documents and services are different sorts of things, instead of using
> a term inconsistently.  

The problem is that inevitably different applications will *need* to use
the same term in inconsistent ways -- not because they ignore the
definition of the term, but because they make finer, but inconsistent
distinctions than the original definition included.

For example, suppose the owner of app0 mints a URI http://example#apple
with a particular URI definition that is given by a set of RDF
assertions involving that URI.  In RDF semantics, an "interpretation"
maps a URI to a resource, and the rules of RDF semantics constrain the
set of interpretations that are possible for a given graph, thus
constraining the set of resources to which that URI may map.  For
brevity I'll call this set of resources the set of possible
*interpretations* for the URI.  So initially, considering only the graph
corresponding to those assertions provided by the definition of
http://example#apple, by the RDF semantics the set of possible
interpretations for http://example#apple corresponding to that graph
will be some set, as illustrated in Figure 2 of
http://dbooth.org/2009/denotation/
Let's call this set R0.  

Now, when app1 adds its own application-specific assertions to the mix
(in combination with the assertions for the definition of
http://example#apple) the set of possible interpretations for
http://example#apple becomes a *subset* of R0.  Let's call this subset
R1.  Fine so far.  But now app2 comes along independently of app1, with
its own application-specific assertions.  Once again, the combination of
app2's assertions and the assertions for the definition of
http://example#apple produce a new set of possible interpretations for
http://example#apple, R2, which is again a subset of R0.  Again, so far
so good.

But what happens when a third application app3 later tries to combine
the assertions used by app1 with the assertions used by app2?  If the
intersection of R1 and R2 is not empty, then all is fine: there are
possible interpretations for http://example#apple.  But if the
intersection is empty we have a problem: http://example#apple has been
used inconsistently between app1 and app2.  Both usages were consistent
with the URI's definition in isolation, but the combination is
inconsistent.  

This is exactly the problem of ambiguity that we've been discussing.
The definition of http://example#apple was ambiguous -- it admitted
multiple interpretations.  And as we know, it is generally not possible
to make a definition admit only one interpretation.  This ambiguity was
not a problem to app0, and it was not a problem to app1 or app2 in
isolation, but it was a problem to app3 that needed to distinguish
between the notion of http://example#apple that app1 used and the notion
that app2 used.

> If *everyone* used http://validator.w3.org/ in
> this way, it could work.
> But if everyone is to use the same scheme, it would seem better to me
> to define a new type that made directly clear the nature of
> http://validator.w3.org/ as being a sort of service which can do two
> different things a) respond with a report about conformance to RDF
> syntax of a supplied document and b) respond with a page that
> documents how (a) works.

Do you mean that http://validator.w3.org/ would denote a resource that
has attributes both of being a Document and of being a Tool?  I.e., it
is both a Document and a Tool?  If so, that sounds reasonable to me.

> Then have two *unambiguous* properties a)
> earl:tool that relates http://validator.w3.org/ to an entity whose
> type is tool, and b) foaf:page that relates to a document. It would be
> helpful to document, as well, that the tool (b) generates a new
> instance of document, each time it is "run".
> -Alan

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.