Splitting vs. Interpreting

[Larry Masinter-3]

The relationship between URIs and resources is intrinsically ambiguous.  To ask the question of how many resources are identified by a single URI is like asking how many angels can be identified by a single pin.

URIs by themselves do not "denote"; they are used by applications or agents to denote or identify. For example,

* XML applications use URIs in xmlns attributes to identify namespaces.

* Hypertext applications such as web browsers use URIs to identify which network resource should be contacted during the interaction with the hypertext and how that contact is to be made.

* Semantic Web applications use URIs to denote concepts. I use "denote" as term related to, but different from, "identify".  Concepts do not form a set, and cannot. Concepts cannot be counted, because to count them, you would have to identify them. There is no 'equality' for concepts.

I believe the question asked by httpRange-14 is ill-formed, because it is based on the presumption that "denotation" is a function, when it is not. I think somehow linking the HTTP response code returned by a server as a way of changing the denotation of a URI used -- well, it's ineffective, misleading, bad design.

I'd normally be reluctant to bring this up -- not a good use of W3C TAG time in my opinion -- but I believe acknowledging the ambiguity may be fundamental to making progress on some of the metadata and security issues before the TAG.

Metadata because metadata itself consists of assertions about media resources in which the identity and scope of the metadata assertion is itself a fundamental ambiguity.  The various means of associating metadata with resources being discussed each carries its own model of what is being described as well as the identity of the describer.

Security because trust is based on the presumption of (sufficient) agreement about the meaning (denotation) of the terms, and disagreement about that results in trust being broken.

Larry
--
http://larry.masinter.net

[Xiaoshu Wang]

Larry Masinter wrote:
> The relationship between URIs and resources is intrinsically ambiguous.  To ask the question of how many resources are identified by a single URI is like asking how many angels can be identified by a single pin.
>
> URIs by themselves do not "denote"; they are used by applications or agents to denote or identify. For example,
>  
Yes.  As Wittginstein has said: "Meaning is use." The URI owner uses the
URI to denote something of his interest.  Other people either agree or
not.  It is as simple as that.

> * XML applications use URIs in xmlns attributes to identify namespaces.
>
> * Hypertext applications such as web browsers use URIs to identify which network resource should be contacted during the interaction with the hypertext and how that contact is to be made.
>
> * Semantic Web applications use URIs to denote concepts. I use "denote" as term related to, but different from, "identify".  Concepts do not form a set, and cannot. Concepts cannot be counted, because to count them, you would have to identify them. There is no 'equality' for concepts.
>
> I believe the question asked by httpRange-14 is ill-formed, because it is based on the presumption that "denotation" is a function, when it is not. I think somehow linking the HTTP response code returned by a server as a way of changing the denotation of a URI used -- well, it's ineffective, misleading, bad design.
>
> I'd normally be reluctant to bring this up -- not a good use of W3C TAG time in my opinion -- but I believe acknowledging the ambiguity may be fundamental to making progress on some of the metadata and security issues before the TAG.
>  

Yes. I have been asking TAG to do that for quite sometime.  Once we get
a clear understanding on the previous question, we can see how much
(non)sense talking about metadata in generic sense.  The most
fundamental concepts of the Web are URI, Resource, Representation.  
Hence, none of these -- meta-URI, meta-Resource, or meta-Representation
-- makes any sense.  So, it may makessense to propose something like
uniform access to DC metadata.  But a uniform way to access "metadata"
without an explict definition?  My bet is that it will be another
httpRange-14.
> Metadata because metadata itself consists of assertions about media resources in which the identity and scope of the metadata assertion is itself a fundamental ambiguity.  The various means of associating metadata with resources being discussed each carries its own model of what is being described as well as the identity of the describer.
>
> Security because trust is based on the presumption of (sufficient) agreement about the meaning (denotation) of the terms, and disagreement about that results in trust being broken.
>
> Larry
>  

[Larry Masinter-3]

My tongue-in-cheek reference to "angels dancing on the head of a pin" confused a few and likely annoyed many; I'm sorry for not indicating humor or a reference, e.g.,  
http://en.wikipedia.org/wiki/How_many_angels_can_stand_on_the_head_of_a_pin%3F 

>    The most  fundamental concepts of the Web are URI, Resource, Representation.  
> Hence, none of these -- meta-URI, meta-Resource, or meta-Representation
> -- makes any sense.  

I don't think we use those terms, so I suppose the fact that they aren't defined isn't too harmful. And I'm not sure those are the "most" salient concepts needed to discuss metadata meaningfully.

I think I have a concept of "metadata" that is worth developing but I need to work on the articulation of it, but here's a shot:

I think of "metadata" as assertions about a resource; resources are, of course, usually identified by a URI, although in some cases you have a representation "in hand" as well as the metadata about it.
Assertions are not "facts" but rather "opinions" (an assertion by an agent of the agent's belief of facts.)

For metadata access, one agent, with a resource identified by a URI or with a representation in hand, needs to discover (an)other agent(s) and to access the metadata (the other agent's opinions about the resource/representation.)

In this model, "trust" by one agent of another is the measure the association of belief: my browser trusts your server to the extent that the browser believes assertions made by your server. And access to metadata on the web then is a matter of finding a trustworthy source of metadata for resources, and establishing conventions where trust can be delegated, e.g., a "link" header is an assertion by a HTTP server that another agent is a reliable authority of metadata for the resources provided by the first.

This is still a little sloppy, but I hope it gives an indication of the direction I'd like to go in metadata access discussions, and the hope that it will be rewarding and not worthy of Xiaoshu's pessimism.

Larry
--
http://larry.masinter.net

[Dan Brickley-2]

On 22/6/09 15:01, Larry Masinter wrote:
> My tongue-in-cheek reference to "angels dancing on the head of a pin" confused a few and likely annoyed many; I'm sorry for not indicating humor or a reference, e.g.,
> http://en.wikipedia.org/wiki/How_many_angels_can_stand_on_the_head_of_a_pin%3F
>
>>     The most  fundamental concepts of the Web are URI, Resource, Representation.
>> Hence, none of these -- meta-URI, meta-Resource, or meta-Representation
>> -- makes any sense.

I quite liked it. It crystalised that sinking feeling I get when certain
topics cross my inbox for the millionth time...

> I don't think we use those terms, so I suppose the fact that they aren't defined isn't too harmful. And I'm not sure those are the "most" salient concepts needed to discuss metadata meaningfully.
>
> I think I have a concept of "metadata" that is worth developing but I need to work on the articulation of it, but here's a shot:
>
> I think of "metadata" as assertions about a resource; resources are, of course, usually identified by a URI, although in some cases you have a representation "in hand" as well as the metadata about it.
> Assertions are not "facts" but rather "opinions" (an assertion by an agent of the agent's belief of facts.)

I tend to write "claim" rather than "assertion", and "thing" rather than
"resource"; besides that, I'm with you so far.

Aside: I think it is also worth noting here that most modern RDF stores
keep track of each "triple" with extra source/provenance information
using URIs, and that the SPARQL language has a construct, "GRAPH" that
allows this to be queried directly, mixed in with normal query constructs.

> For metadata access, one agent, with a resource identified by a URI or with a representation in hand, needs to discover (an)other agent(s) and to access the metadata (the other agent's opinions about the resource/representation.)
>
> In this model, "trust" by one agent of another is the measure the association of belief: my browser trusts your server to the extent that the browser believes assertions made by your server. And access to metadata on the web then is a matter of finding a trustworthy source of metadata for resources, and establishing conventions where trust can be delegated, e.g., a "link" header is an assertion by a HTTP server that another agent is a reliable authority of metadata for the resources provided by the first.

I think I'm still with you, though starting to feel that my reading
"resource" as "thing" was a more significant parting of company.
"Resource" here is something like document-like-object or http:Resource?

> This is still a little sloppy, but I hope it gives an indication of the direction I'd like to go in metadata access discussions, and the hope that it will be rewarding and not worthy of Xiaoshu's pessimism.

Seems constructive so far...

cheers,

Dan

[john.1.kemp]

> -----Original Message-----
> From: www-tag-request@... [mailto:www-tag-request@...] On Behalf
> Of ext Larry Masinter
> Sent: Monday, June 22, 2009 9:01 AM
> To: Xiaoshu Wang
> Cc: www-tag
> Subject: metadata, resources, and angels & pins

[...]

> I think of "metadata" as assertions about a resource; resources are, of
> course, usually identified by a URI, although in some cases you have a
> representation "in hand" as well as the metadata about it.
> Assertions are not "facts" but rather "opinions" (an assertion by an
> agent of the agent's belief of facts.)

Indeed this is sounding a bit like security architecture terminology, such as defined by RFC 2828 [1], SAML[2] and others, where an agent makes a claim or assertion about a named subject (perhaps naming that subject with a URI), and other agents may verify the assertions about the named subject, perhaps based on their level of trust in the agent making the claim.

[...]

> This is still a little sloppy, but I hope it gives an indication of the
> direction I'd like to go in metadata access discussions, and the hope
> that it will be rewarding and not worthy of Xiaoshu's pessimism.

It certainly sounds workable so far.

Regards,

- johnk

[1] http://www.ietf.org/rfc/rfc2828.txt
[2] http://en.wikipedia.org/wiki/SAML_2.0

[Pat Hayes]

On Jun 19, 2009, at 10:05 PM, Larry Masinter wrote:

> The relationship between URIs and resources is intrinsically  
> ambiguous.  To ask the question of how many resources are identified  
> by a single URI is like asking how many angels can be identified by  
> a single pin.
>
> URIs by themselves do not "denote"

Yes they do. (And without scare quotes, by the way.)

> ; they are used by applications or agents to denote or identify.

The only way an agent can denote (with language) is to use a denoting  
name. Its the names that do the denoting.

> For example,
>
> * XML applications use URIs in xmlns attributes to identify  
> namespaces.
>
> * Hypertext applications such as web browsers use URIs to identify  
> which network resource should be contacted during the interaction  
> with the hypertext and how that contact is to be made.
>
> * Semantic Web applications use URIs to denote concepts.

No, they denote things. Usually fairly concrete things, such as people  
and companies and towns, things like that.

> I use "denote" as term related to, but different from, "identify".

Well, 'denotation' is a term with a well-established meaning. So far,  
in several years of reading and asking, I have never seen or heard  
anyone who can say what "identify" means.

>  Concepts do not form a set, and cannot.

Nonsense. Anything can form a set. That is, a set can contain anything.

> Concepts cannot be counted, because to count them, you would have to  
> identify them. There is no 'equality' for concepts.

There is equality for anything that anyone can talk about. Equality  
means, being the same. Things - all things - are the same as  
themselves, and not the same as anything else. End of story for  
equality. This has nothing to do with counting. Uncountable sets of,  
say, the inaccessible cardinals, still have elements which are equal  
to themselves. The only way to make sense of what you say here is to  
take it as a rhetorical way of saying that the idea of "concept" is  
broken or useless, as nobody knows what that word means. Which is not  
an unreasonable conclusion, but also not germane to anything, as URIs  
in OWL and RDFS do not denote concepts of things: they denote the  
actual things.

> Aq `1` 12xz90-
> I believe the question asked by httpRange-14 is ill-formed, because  
> it is based on the presumption that "denotation" is a function, when  
> it is not.

It is in a given interpretation. One way to express the intent of http-
range-14 is to express it as a constraint on interpretations: URIs  
which return 200-code http responses are required to denote (in any  
'web-legal', or maybe 'tag-approved', interpretation) a Web resource  
which emitted that response (or whatever the current http-range-14  
decision actually is.) And then, the ruling amounts to saying that  
only web-legal interpretations should be considered when asking  
questions about validity, entailment, etc. This gets neatly past the  
objection that there isn't a single unique referent to be picked out.  
There doesn't need to be: there just needs to be a well-formed  
constraint on the possible referents.

> I think somehow linking the HTTP response code returned by a server  
> as a way of changing the denotation of a URI used -- well, it's  
> ineffective, misleading, bad design.

Well, I tend to agree with that, but I also can't see any viable  
alternative. So here we are in a mess that needs to be handled  
somehow, and (as with democracy) this is a lousy idea, but all the  
other ideas are worse.

>
> I'd normally be reluctant to bring this up -- not a good use of W3C  
> TAG time in my opinion -- but I believe acknowledging the ambiguity  
> may be fundamental to making progress on some of the metadata and  
> security issues before the TAG.
>
> Metadata because metadata itself consists of assertions about media  
> resources in which the identity and scope of the metadata assertion  
> is itself a fundamental ambiguity.  The various means of associating  
> metadata with resources being discussed each carries its own model  
> of what is being described as well as the identity of the describer.

Well, that last part is probably true, but it doesnt follow that  
anything is ambiguous, only that the various means might not be in  
perfect alignment. Which is certainly an important topic to address,  
but its also important not to get it confused with other issues, like  
ambiguity. IMO ambiguity is inevitable and not centrally important,  
but this one is.

>
> Security because trust is based on the presumption of (sufficient)  
> agreement about the meaning (denotation) of the terms, and  
> disagreement about that results in trust being broken.

It results in EVERYTHING being broken, not just trust. Confucious was  
pretty clear on that point: "If names be not in accord with the truth  
of things, ... plans cannot be carried out to success"

Pat


>
> Larry
> --
> http://larry.masinter.net
>

------------------------------------------------------------
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

[Pat Hayes]

On Jun 22, 2009, at 8:01 AM, Larry Masinter wrote:

> My tongue-in-cheek reference to "angels dancing on the head of a  
> pin" confused a few and likely annoyed many; I'm sorry for not  
> indicating humor or a reference, e.g.,
> http://en.wikipedia.org/wiki/How_many_angels_can_stand_on_the_head_of_a_pin%3F
>
>>   The most  fundamental concepts of the Web are URI, Resource,  
>> Representation.
>> Hence, none of these -- meta-URI, meta-Resource, or meta-
>> Representation
>> -- makes any sense.  
>
> I don't think we use those terms, so I suppose the fact that they  
> aren't defined isn't too harmful. And I'm not sure those are the  
> "most" salient concepts needed to discuss metadata meaningfully.
>
> I think I have a concept of "metadata" that is worth developing but  
> I need to work on the articulation of it, but here's a shot:
>
> I think of "metadata" as assertions about a resource; resources are,  
> of course, usually identified by a URI, although in some cases you  
> have a representation "in hand" as well as the metadata about it.
> Assertions are not "facts" but rather "opinions" (an assertion by an  
> agent of the agent's belief of facts.)
>
> For metadata access, one agent, with a resource identified by a URI  
> or with a representation in hand, needs to discover (an)other  
> agent(s) and to access the metadata (the other agent's opinions  
> about the resource/representation.)
>
> In this model, "trust" by one agent of another is the measure the  
> association of belief: my browser trusts your server to the extent  
> that the browser believes assertions made by your server.

That sounds like the consequence of trust rather than a definition. As  
a definition it is kind of circular.

> And access to metadata on the web then is a matter of finding a  
> trustworthy source

which means, by the above, one that I am inclined to believe what it  
says. Well, yes, but that doesnt seem to get us anywhere. WHY are you  
more inclined to believe this one? Because you trust it...?

Pat

> of metadata for resources, and establishing conventions where trust  
> can be delegated, e.g., a "link" header is an assertion by a HTTP  
> server that another agent is a reliable authority of metadata for  
> the resources provided by the first.
>
> This is still a little sloppy, but I hope it gives an indication of  
> the direction I'd like to go in metadata access discussions, and the  
> hope that it will be rewarding and not worthy of Xiaoshu's pessimism.
>
> Larry
> --
> http://larry.masinter.net

------------------------------------------------------------
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

[Xiaoshu Wang]

Larry Masinter wrote:

> My tongue-in-cheek reference to "angels dancing on the head of a pin" confused a few and likely annoyed many; I'm sorry for not indicating humor or a reference, e.g.,  
> http://en.wikipedia.org/wiki/How_many_angels_can_stand_on_the_head_of_a_pin%3F 
>
>  
>>    The most  fundamental concepts of the Web are URI, Resource, Representation.  
>> Hence, none of these -- meta-URI, meta-Resource, or meta-Representation
>> -- makes any sense.  
>>    
>
> I don't think we use those terms, so I suppose the fact that they aren't defined isn't too harmful. And I'm not sure those are the "most" salient concepts needed to discuss metadata meaningfully.
>  

Of course we don't because they do not make sense.  And that is my
point.  "Metadata" whatever it is, must be either be a URI, a
Representation, or a Resource.  Proposing anything else implies a
fundamentally different web architecture than what we know.
> I think I have a concept of "metadata" that is worth developing but I need to work on the articulation of it, but here's a shot:
>
> I think of "metadata" as assertions about a resource; resources are, of course, usually identified by a URI, although in some cases you have a representation "in hand" as well as the metadata about it.
> Assertions are not "facts" but rather "opinions" (an assertion by an agent of the agent's belief of facts.)
>  
Well, first, RDF is about assertions.

Yes, the second one can make some sense, that is, "you have a
representation in hand as well as metadata".  But representation is
inherently different from resource, in that it is a structure.  Then, if
I know the structure that I intends, then it makes sense to get its
metadata.  But, one URI denote one resource, which in turn have multiple
representations.  Then, if we want to define a generic way to getting
the metadata of a *representation*, which one we are talking about?  I
have mentioned a few times in this list, you can only use content
negotiation to make any pragmatic sense.

Facts and opinion's are not that much different.  They only differ in
the scope, in which the assertions is taking to be true.

> For metadata access, one agent, with a resource identified by a URI or with a representation in hand, needs to discover (an)other agent(s) and to access the metadata (the other agent's opinions about the resource/representation.)
>  
See above. One resource does NOT have one, but have multiple
representation.
> In this model, "trust" by one agent of another is the measure the association of belief: my browser trusts your server to the extent that the browser believes assertions made by your server. And access to metadata on the web then is a matter of finding a trustworthy source of metadata for resources, and establishing conventions where trust can be delegated, e.g., a "link" header is an assertion by a HTTP server that another agent is a reliable authority of metadata for the resources provided by the first.
>  
Within the context of an HTTP message, it makes sense to say Headers are
the "metadata" of the "entity" because the sole purpose of knowing the
headers is for the correct parsing of the "entity".  To get the
"metadata" for a "resource" makes no sense at all.  First, as a URI
owner, how do I know what kind of content that I should put in the
"entity" and which part the "metadata".  Second, for a client, how do I
know which content that I will be interested?  Think how we are going to
implement a browser, if we take any of these so-called "uniform-access
to metadata".  Should the browser parse both the HTTP "entity" and the
"metadata" and present to its client? Or choose a single one?  If so,
how? If not, then what is the point of the "metadata"?

> This is still a little sloppy, but I hope it gives an indication of the direction I'd like to go in metadata access discussions, and the hope that it will be rewarding and not worthy of Xiaoshu's pessimism.
>  
I am not pessimistic by nature.  I am just the opposite.  And I am
pragmatic too.  I have opposed any kind of uniform access to metadata
approach because it provide no benefit whatsoever.  Honestly, take what
the LINK proposal and see if there  is any difference between it and an
RDF doc?  The terminology might be different but they are the same
triple model.  What is implied from this is that:  all the so-called
metadata approach assumes: there is an objective criteria with whhich we
can split an RDF graph in two parts, one "data" part and the other
"meta" part.  I challenge anyone to establish that definition.  If not,
then we know what is the fallacy of the so-called "uniform approach to
access metadata".

The more meaningful and pragmatic way is, as I write in another
manuscript, to complete the URI syntax so that we can (1) give URI
itself a syntax. (2) to discover all potential representations, i.e.,
media-type associated with a resource, (3) to denote a representation.  
This will make URI's referential range *syntactically* complete with
regard to the three fundamental concepts of the Web -- URI, resource,
representation.

Then, given a URI, we can find out what kind of services (service and
format are semantically equivalent at the most fundamental level) that a
resource supports.  Each specific kind of "metadata discovery" can be
defined as a special MIME-type (which I also think need to be URIzed).
Then, the client subsequently negotiate over that content type to get
what they want. This is the only way that makes sense and pragmatic.  I
don't see any other ways.

Xiaoshu

[David Booth-6]

On Thu, 2009-06-18 at 17:34 +0100, Sean B. Palmer wrote:
> 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?

Okay, since you asked . . .  ;)  I'd suggest the following changes.

1. The first three paragraphs of section 2.2 currently read:
http://www.w3.org/TR/webarch/#id-resources
[[
By design a URI identifies one resource. We do not limit the scope of
what might be a resource. The term "resource" is used in a general sense
for whatever might be identified by a URI. It is conventional on the
hypertext Web to describe Web pages, images, product catalogs, etc. as
“resources”. The distinguishing characteristic of these resources is
that all of their essential characteristics can be conveyed in a
message. We identify this set as “information resources.”

This document is an example of an information resource. It consists of
words and punctuation symbols and graphics and other artifacts that can
be encoded, with varying degrees of fidelity, into a sequence of bits.
There is nothing about the essential information content of this
document that cannot in principle be transfered in a message. In the
case of this document, the message payload is the representation of this
document.

However, our use of the term resource is intentionally more broad. Other
things, such as cars and dogs (and, if you've printed this document on
physical sheets of paper, the artifact that you are holding in your
hand), are resources too. They are not information resources, however,
because their essence is not information. Although it is possible to
describe a great many things about a car or a dog in a sequence of bits,
the sum of those things will invariably be an approximation of the
essential character of the resource.
]]

I suggest changing the above paragraphs to:
[[
By design a URI identifies one resource.  The term "resource" is used in
a general sense for whatever might be identified by a URI.  We do not
limit the scope of what might be a resource.  A resource could be
anything that one may wish to identify --  physical, conceptual, real or
imaginary.  

An "information resource" is any resource that plays a role in the
hypertext Web by producing "representations"[link to definition in sec
3.2] in response to Web requests.  Web pages, images, product catalogs
and other things that are made available on the Web are all information
resources.  Some information resources, such as static web pages, may
change very little or not at all over time.  Others, such as one that
displays the current weather report for Oaxaca, may vary frequently.
Similarly, some information resources, such as an interactive travel
booking site, may vary their representations depending on their
requests.  Others, such as simple Web pages, may not.  Conceptually one
can think of an information resource as a function from time and request
to representation.

Ambiguity of Resource Identity

Although a URI is intended to identify one resource, and ambiguity about
the identity of that resource should be avoided to the extent possible,
ultimately ambiguity is in the eye -- or the application -- of the
beholder.  Because anything can be a resource, what one party considers
a single resource (perhaps having multiple aspects) another party making
finer distinctions might consider multiple resources that should have
distinct URIs.  

For example, the content of a book may be placed on the web and
identified by a particular URI.  Many parties will have no need to
distinguish between the web page that provides the content of the book
and the content of the book as an artistic work that is subject to
copyright law.  Depending on one's perspective (or application) this may
be viewed as a case in which the URI unambiguously identifies a resource
that has multiple aspects or as a case of ambiguity, in which the
artistic work and the web page are each deserving of their own distinct
URIs.

Resources whose essential characteristics can be conveyed in message are
good candidates for being considered information resources.  Other
things, such as cars and people are less good, because some applications
are likely to find them ambiguous.  For example, if the same URI is used
to directly identify both a person and a Web page -- an information
resource -- an application that records the creation dates of people and
Web pages may find this resource ambiguous, because it cannot
distinguish between the creation date of the person and the creation
date of the web page.  This ambiguity would be avoided by giving the
person and the web page separate URIs.  On the other hand, the use of
two separate URIs may impart a cost to other applications that have no
need to distinguish between the person and the Web page, because it
requires these applications to recognize two URIs that those
applications consider equivalent.
]]

2. The current definition of "representation" reads:
http://www.w3.org/TR/webarch/#internet-media-type
[[
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".
]]

I suggest changing this to:
[[
A representation is a response, from an information resource, that
encodes information reflecting that information resource's state.
Representations do not necessarily describe the information resource, or
portray a likeness of the resource, or represent the resource in other
senses of the word "represent".  Only an information resource can have
representations in the sense used herein.
]]

3. In addition to the above changes, there are many instances of the
word "resource" that should be changed to "information resource",
because the context only applies to information resources -- not
resources in general.  


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

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

[Sean B. Palmer]

On Mon, Jul 13, 2009 at 3:24 AM, David Booth<david@...> wrote:

> By design a URI identifies one resource.  The term "resource" is
> used in a general sense for whatever might be identified by a URI.

What would these sentences look like if they were written with
something more like the HTML 5 philosophy?

When you look at deployed usage, obviously you find that the http
scheme is used far more widely than any other scheme. What's the
second most commonly used scheme? mailto? file?

I'm sure TimBL now rues using mailto instead of mailbox or mbox or
some such. If you were to ask someone how many things a file URI
identifies, what would they say?

file:///tmp/example.txt

How many /tmp/example.txt files in the world? Okay, but it only refers
to the file on the current system. So in that case, is that a product
of behaviour or is it a reference system?

When browser manufacturers come up with new schemes, what kind of
things are they commonly making and why?

Safari redirects any http URI that returns application/atom+xml to the
same URI string only with feed in place of the http scheme. What the
heck is that all about? What is AWWW teaching us about this, or is
this not within AWWW's remit?

The most common use of a URI is clicking a link in HTML or pasting it
in your browser's address bar. And we're not talking most common by a
slight majority, of course.

So if we add up all the other uses of URIs, your mailboxes and your
file URIs and your XML namespaces and your URNs and tags and all kinds
of things, do they amount to the same body of usage as HTTP URIs used
in the browser?

And if we look at the commonalities amongst how these things are used
and implemented, what do we want to derive from that? What can we
learn, and what can we teach?

> An "information resource" is any resource that plays a role
> in the hypertext Web by producing "representations"

What server actually works on a model of resources producing
representations? What web framework works in this way? I've just been
through the Django tutorial, and I don't see resource being used in
there.

The simple use of current common servers is that files in directories
are exposed on the web, and maybe you can leave the file extensions
off. More complex use involves scripting. To someone coding the
backend to the latest Web 2.0 startup, does "information resources
produce representations" mean anything?

If not, where are the extents of the remit again?

If servers were commonly implemented in Analytica, Lusture, or Prolog,
that might be one thing. Heck, when I wrote an HTTP client
implementation in Python I tried to use all the right words from RFC
2616. What does your sentence tell me that RFC 2616 doesn't?

> Depending on one's perspective (or application) this may be
> viewed as a case in which the URI unambiguously identifies
> a resource that has multiple aspects or as a case of ambiguity,
> in which the artistic work and the web page are each deserving
> of their own distinct URIs.

Okay this, to me, is a very admirable attempt to resolve the current
peculiarities of the situation that we're working on here.

But why are you saying this? You're only saying this because of RDF,
not because of some common model of the web. And yet this is
Architecture of the World Wide Web.

So don't say that here. It's the wrong place!

Now there is an argument that the web was always like this, and that
the common and general model came first. But if that were so, we
wouldn't be having to define it now. And we wouldn't have "mailto".

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

[David Booth-6]

Hi Sean,

On Mon, 2009-07-13 at 10:55 +0100, Sean B. Palmer wrote:
> On Mon, Jul 13, 2009 at 3:24 AM, David Booth<david@...> wrote:
>
> > By design a URI identifies one resource.  The term "resource" is
> > used in a general sense for whatever might be identified by a URI.
>
> What would these sentences look like if they were written with
> something more like the HTML 5 philosophy?

I don't think I know well enough what the HTML 5 philosophy is to
comment.

>
> When you look at deployed usage, obviously you find that the http
> scheme is used far more widely than any other scheme. What's the
> second most commonly used scheme? mailto? file?
>
> I'm sure TimBL now rues using mailto instead of mailbox or mbox or
> some such. If you were to ask someone how many things a file URI
> identifies, what would they say?
>
> file:///tmp/example.txt
>
> How many /tmp/example.txt files in the world? Okay, but it only refers
> to the file on the current system. So in that case, is that a product
> of behaviour or is it a reference system?

Yes, that's a good corner case, as that's one that is specifically
designed to be context dependent. So in theory it identifies a single
abstract resource -- the idea of *some* file with that name -- but in
practice context is used to map it to a more concrete, specific file.
In other words, in theory it can still be viewed as identifying a single
thing, but in practice the thing it identifies depends on context.  

>
> When browser manufacturers come up with new schemes, what kind of
> things are they commonly making and why?
>
> Safari redirects any http URI that returns application/atom+xml to the
> same URI string only with feed in place of the http scheme. What the
> heck is that all about? What is AWWW teaching us about this, or is
> this not within AWWW's remit?

Do you mean Safari makes up a new URI for it?  Something like
  feed://example/my-feed
instead of
  http://example/my-feed 
?  
That seems a little odd, since it already knows that it has an atom
feed.  Do you know what is the rationale for doing this?

>
> The most common use of a URI is clicking a link in HTML or pasting it
> in your browser's address bar. And we're not talking most common by a
> slight majority, of course.
>
> So if we add up all the other uses of URIs, your mailboxes and your
> file URIs and your XML namespaces and your URNs and tags and all kinds
> of things, do they amount to the same body of usage as HTTP URIs used
> in the browser?
>
> And if we look at the commonalities amongst how these things are used
> and implemented, what do we want to derive from that? What can we
> learn, and what can we teach?

Not sure what you're getting at.  Are you suggesting a completely
different approach to the AWWW's treatment of URIs identifying
resources?

>
> > An "information resource" is any resource that plays a role
> > in the hypertext Web by producing "representations"
>
> What server actually works on a model of resources producing
> representations? What web framework works in this way? I've just been
> through the Django tutorial, and I don't see resource being used in
> there.

They all work in this way, though not necessarily using that
terminology.  That's just the terminology chosen by AWWW to describe, at
an abstract level, what happens.  I've simply tried to be as consistent
as possible with existing AWWW terminology while suggesting changes that
would correct the current, flawed definition of "information resource".
Trying to change the terminology beyond that might be useful, but it
would be a much bigger undertaking and is outside the scope of my
suggestion.

>
> The simple use of current common servers is that files in directories
> are exposed on the web, and maybe you can leave the file extensions
> off. More complex use involves scripting. To someone coding the
> backend to the latest Web 2.0 startup, does "information resources
> produce representations" mean anything?
>
> If not, where are the extents of the remit again?
>
> If servers were commonly implemented in Analytica, Lusture, or Prolog,
> that might be one thing. Heck, when I wrote an HTTP client
> implementation in Python I tried to use all the right words from RFC
> 2616. What does your sentence tell me that RFC 2616 doesn't?

Not very much.  :)   It just states it in AWWW terms.

>
> > Depending on one's perspective (or application) this may be
> > viewed as a case in which the URI unambiguously identifies
> > a resource that has multiple aspects or as a case of ambiguity,
> > in which the artistic work and the web page are each deserving
> > of their own distinct URIs.
>
> Okay this, to me, is a very admirable attempt to resolve the current
> peculiarities of the situation that we're working on here.
>
> But why are you saying this? You're only saying this because of RDF,
> not because of some common model of the web. And yet this is
> Architecture of the World Wide Web.
>
> So don't say that here. It's the wrong place!

In some ways I agree, that it would be more appropriate to put the
material on ambiguity in a separate document on semantic web
architecture (which builds on web architecture, of course).  The reason
I included it here is that that is the only way I can see to explain
what's going on when someone uses the same URI for both a person and a
web page, and someone else complains that that creates an ambiguity.
IMO a critical flaw in the current definition of "information resource"
is the suggestion that it is a class of things that is disjoint from the
class of people or cars or dogs.  I guess the erratum could just remove
the disjointness constraint without further explaining it, but it seemed
to me that people would likely want more of an explanation.

On the other hand, the AWWW *is* already laying the groundwork for RDF
and the semantic web, by talking about URIs identifying things other
than web pages.  And as soon as you talk about a URI identifying one
resource, the issue of ambiguity starts to appear, so it seems difficult
to know how to separate it.


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

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

[Xiaoshu Wang-3]

David Booth wrote:

> Hi Sean,
>
> On Mon, 2009-07-13 at 10:55 +0100, Sean B. Palmer wrote:
>  
>> On Mon, Jul 13, 2009 at 3:24 AM, David Booth<david@...> wrote:
>>
>>    
>>> By design a URI identifies one resource.  The term "resource" is
>>> used in a general sense for whatever might be identified by a URI.
>>>      
>> What would these sentences look like if they were written with
>> something more like the HTML 5 philosophy?
>>    
>
> I don't think I know well enough what the HTML 5 philosophy is to
> comment.
>
>  
>> When you look at deployed usage, obviously you find that the http
>> scheme is used far more widely than any other scheme. What's the
>> second most commonly used scheme? mailto? file?
>>
>> I'm sure TimBL now rues using mailto instead of mailbox or mbox or
>> some such. If you were to ask someone how many things a file URI
>> identifies, what would they say?
>>
>> file:///tmp/example.txt
>>
>> How many /tmp/example.txt files in the world? Okay, but it only refers
>> to the file on the current system. So in that case, is that a product
>> of behaviour or is it a reference system?
>>    
>
> Yes, that's a good corner case, as that's one that is specifically
> designed to be context dependent. So in theory it identifies a single
> abstract resource -- the idea of *some* file with that name -- but in
> practice context is used to map it to a more concrete, specific file.
> In other words, in theory it can still be viewed as identifying a single
> thing, but in practice the thing it identifies depends on context.  
>
>  
>> When browser manufacturers come up with new schemes, what kind of
>> things are they commonly making and why?
>>
>> Safari redirects any http URI that returns application/atom+xml to the
>> same URI string only with feed in place of the http scheme. What the
>> heck is that all about? What is AWWW teaching us about this, or is
>> this not within AWWW's remit?
>>    
>
> Do you mean Safari makes up a new URI for it?  Something like
>   feed://example/my-feed
> instead of
>   http://example/my-feed 
> ?  
> That seems a little odd, since it already knows that it has an atom
> feed.  Do you know what is the rationale for doing this?
>
>  
>> The most common use of a URI is clicking a link in HTML or pasting it
>> in your browser's address bar. And we're not talking most common by a
>> slight majority, of course.
>>
>> So if we add up all the other uses of URIs, your mailboxes and your
>> file URIs and your XML namespaces and your URNs and tags and all kinds
>> of things, do they amount to the same body of usage as HTTP URIs used
>> in the browser?
>>
>> And if we look at the commonalities amongst how these things are used
>> and implemented, what do we want to derive from that? What can we
>> learn, and what can we teach?
>>    
>
> Not sure what you're getting at.  Are you suggesting a completely
> different approach to the AWWW's treatment of URIs identifying
> resources?
>
>  
>>> An "information resource" is any resource that plays a role
>>> in the hypertext Web by producing "representations"
>>>      
>> What server actually works on a model of resources producing
>> representations? What web framework works in this way? I've just been
>> through the Django tutorial, and I don't see resource being used in
>> there.
>>    
>
> They all work in this way, though not necessarily using that
> terminology.  That's just the terminology chosen by AWWW to describe, at
> an abstract level, what happens.  I've simply tried to be as consistent
> as possible with existing AWWW terminology while suggesting changes that
> would correct the current, flawed definition of "information resource".
> Trying to change the terminology beyond that might be useful, but it
> would be a much bigger undertaking and is outside the scope of my
> suggestion.
>
>  
>> The simple use of current common servers is that files in directories
>> are exposed on the web, and maybe you can leave the file extensions
>> off. More complex use involves scripting. To someone coding the
>> backend to the latest Web 2.0 startup, does "information resources
>> produce representations" mean anything?
>>
>> If not, where are the extents of the remit again?
>>
>> If servers were commonly implemented in Analytica, Lusture, or Prolog,
>> that might be one thing. Heck, when I wrote an HTTP client
>> implementation in Python I tried to use all the right words from RFC
>> 2616. What does your sentence tell me that RFC 2616 doesn't?
>>    
>
> Not very much.  :)   It just states it in AWWW terms.
>
>  
>>> Depending on one's perspective (or application) this may be
>>> viewed as a case in which the URI unambiguously identifies
>>> a resource that has multiple aspects or as a case of ambiguity,
>>> in which the artistic work and the web page are each deserving
>>> of their own distinct URIs.
>>>      
>> Okay this, to me, is a very admirable attempt to resolve the current
>> peculiarities of the situation that we're working on here.
>>
>> But why are you saying this? You're only saying this because of RDF,
>> not because of some common model of the web. And yet this is
>> Architecture of the World Wide Web.
>>
>> So don't say that here. It's the wrong place!
>>    
>
> In some ways I agree, that it would be more appropriate to put the
> material on ambiguity in a separate document on semantic web
> architecture (which builds on web architecture, of course).  The reason
> I included it here is that that is the only way I can see to explain
> what's going on when someone uses the same URI for both a person and a
> web page, and someone else complains that that creates an ambiguity.
>  

The word "ambiguity" is itself ambiguous without an explicitly specified
ontological ground.  *Who * says, or *where* does it say, that it is
ambiguous if a URI denotes both a person and a web page (what is a web
page anyway)?  The semantics is, in fact, quite clear: the URI's
referent is what it is -- a person and a web page.  It is no different
if I switch "person" to "parent" and "web page" to "child".  Is it
ambiguous or clear if I say that I am both a parent and a child?

The Web Architecture does not specify an ontological ground for the
ambiguity about those things, So let us not use it to imply what is
ambiguous and what is not.  The only kind of ambiguity that we can say
at the AWWW level is that, given a URI, whether the referent is a
resource, a URI, or representation.  The latter three kind of things is
all we know about the Web.

> IMO a critical flaw in the current definition of "information resource"
> is the suggestion that it is a class of things that is disjoint from the
> class of people or cars or dogs.  I guess the erratum could just remove
> the disjointness constraint without further explaining it, but it seemed
> to me that people would likely want more of an explanation.
>  
The critical flaw of the IR is the idea behind it.  Take IR out of AWWW,
we are all relieved.

Xiaoshu

[Larry Masinter-3]

I've updated the "tdb" document (removing duri)
as a contribution to the puzzle of
"URI for abstract concept":

http://www.ietf.org/internet-drafts/draft-masinter-dated-uri-06.txt

It provides a way of creating a URI that can identify
anything that you can describe.

I don't want to start the meta-discussion on the www-tag
mailing list, but I would appreciate (private, or cc'd to
www-archive only if you prefer), reasons why you think
resolving this is of higher priority than the other
topics the TAG is now considering.

For my part (and I think I'm an outlier on the TAG alas)
I am not at all convinced that this topic meets all of the
criteria I have for what I think should be high priority
for the tag: something we can resolve, will likely have an
effect on the participants in Web architecture, in which
the TAG has expertise, is relevant to the ongoing
important work of W3C groups, is not better addressed
by specific working groups chartered for the purpose,
...

I'm not particularly happy (personally) with what the
AWWW document says about "information resources", but
why is it important for the TAG to spend a lot of time
fixing?

Thanks,

Larry
--
http://larry.masinter.net



-----Original Message-----
From: www-tag-request@... [mailto:www-tag-request@...] On Behalf Of David Booth
Sent: Sunday, July 12, 2009 7:25 PM
To: Sean B. Palmer
Cc: www-tag@...
Subject: Proposed AWWW erratum on "information resources" [was Re: Fwd: Splitting vs. Interpreting]

On Thu, 2009-06-18 at 17:34 +0100, Sean B. Palmer wrote:
> 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?

Okay, since you asked . . .  ;)  I'd suggest the following changes.

1. The first three paragraphs of section 2.2 currently read:
http://www.w3.org/TR/webarch/#id-resources
[[
By design a URI identifies one resource. We do not limit the scope of
what might be a resource. The term "resource" is used in a general sense
for whatever might be identified by a URI. It is conventional on the
hypertext Web to describe Web pages, images, product catalogs, etc. as
“resources”. The distinguishing characteristic of these resources is
that all of their essential characteristics can be conveyed in a
message. We identify this set as “information resources.”

This document is an example of an information resource. It consists of
words and punctuation symbols and graphics and other artifacts that can
be encoded, with varying degrees of fidelity, into a sequence of bits.
There is nothing about the essential information content of this
document that cannot in principle be transfered in a message. In the
case of this document, the message payload is the representation of this
document.

However, our use of the term resource is intentionally more broad. Other
things, such as cars and dogs (and, if you've printed this document on
physical sheets of paper, the artifact that you are holding in your
hand), are resources too. They are not information resources, however,
because their essence is not information. Although it is possible to
describe a great many things about a car or a dog in a sequence of bits,
the sum of those things will invariably be an approximation of the
essential character of the resource.
]]

I suggest changing the above paragraphs to:
[[
By design a URI identifies one resource.  The term "resource" is used in
a general sense for whatever might be identified by a URI.  We do not
limit the scope of what might be a resource.  A resource could be
anything that one may wish to identify --  physical, conceptual, real or
imaginary.  

An "information resource" is any resource that plays a role in the
hypertext Web by producing "representations"[link to definition in sec
3.2] in response to Web requests.  Web pages, images, product catalogs
and other things that are made available on the Web are all information
resources.  Some information resources, such as static web pages, may
change very little or not at all over time.  Others, such as one that
displays the current weather report for Oaxaca, may vary frequently.
Similarly, some information resources, such as an interactive travel
booking site, may vary their representations depending on their
requests.  Others, such as simple Web pages, may not.  Conceptually one
can think of an information resource as a function from time and request
to representation.

Ambiguity of Resource Identity

Although a URI is intended to identify one resource, and ambiguity about
the identity of that resource should be avoided to the extent possible,
ultimately ambiguity is in the eye -- or the application -- of the
beholder.  Because anything can be a resource, what one party considers
a single resource (perhaps having multiple aspects) another party making
finer distinctions might consider multiple resources that should have
distinct URIs.  

For example, the content of a book may be placed on the web and
identified by a particular URI.  Many parties will have no need to
distinguish between the web page that provides the content of the book
and the content of the book as an artistic work that is subject to
copyright law.  Depending on one's perspective (or application) this may
be viewed as a case in which the URI unambiguously identifies a resource
that has multiple aspects or as a case of ambiguity, in which the
artistic work and the web page are each deserving of their own distinct
URIs.

Resources whose essential characteristics can be conveyed in message are
good candidates for being considered information resources.  Other
things, such as cars and people are less good, because some applications
are likely to find them ambiguous.  For example, if the same URI is used
to directly identify both a person and a Web page -- an information
resource -- an application that records the creation dates of people and
Web pages may find this resource ambiguous, because it cannot
distinguish between the creation date of the person and the creation
date of the web page.  This ambiguity would be avoided by giving the
person and the web page separate URIs.  On the other hand, the use of
two separate URIs may impart a cost to other applications that have no
need to distinguish between the person and the Web page, because it
requires these applications to recognize two URIs that those
applications consider equivalent.
]]

2. The current definition of "representation" reads:
http://www.w3.org/TR/webarch/#internet-media-type
[[
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".
]]

I suggest changing this to:
[[
A representation is a response, from an information resource, that
encodes information reflecting that information resource's state.
Representations do not necessarily describe the information resource, or
portray a likeness of the resource, or represent the resource in other
senses of the word "represent".  Only an information resource can have
representations in the sense used herein.
]]

3. In addition to the above changes, there are many instances of the
word "resource" that should be changed to "information resource",
because the context only applies to information resources -- not
resources in general.  


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

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

[David Booth-6]

Hi Larry,

I think we're talking about two different things here: the proposed tdb:
scheme, and the definition of "information resource".  I don't think I
can offer the TAG specific input on what should be considered a higher
priority than what else, but in general I would say:

 - URIs are the foundation of the Web, and the network effect is
important, hence the proliferation of URI schemes is important to
prevent.

 - Consternation over the definition of "information resource" (and the
related httpRange-14 issue) has been a persistent thorn for a long time,
consuming much aggregate brain power.  It would be nice to lay it to
rest (if possible).

David Booth


On Mon, 2009-07-13 at 09:04 -0700, Larry Masinter wrote:

> I've updated the "tdb" document (removing duri)
> as a contribution to the puzzle of
> "URI for abstract concept":
>
> http://www.ietf.org/internet-drafts/draft-masinter-dated-uri-06.txt
>
> It provides a way of creating a URI that can identify
> anything that you can describe.
>
> I don't want to start the meta-discussion on the www-tag
> mailing list, but I would appreciate (private, or cc'd to
> www-archive only if you prefer), reasons why you think
> resolving this is of higher priority than the other
> topics the TAG is now considering.
>
> For my part (and I think I'm an outlier on the TAG alas)
> I am not at all convinced that this topic meets all of the
> criteria I have for what I think should be high priority
> for the tag: something we can resolve, will likely have an
> effect on the participants in Web architecture, in which
> the TAG has expertise, is relevant to the ongoing
> important work of W3C groups, is not better addressed
> by specific working groups chartered for the purpose,
> ...
>
> I'm not particularly happy (personally) with what the
> AWWW document says about "information resources", but
> why is it important for the TAG to spend a lot of time
> fixing?
>
> Thanks,
>
> Larry
> --
> http://larry.masinter.net
>
>
>
> -----Original Message-----
> From: www-tag-request@... [mailto:www-tag-request@...] On Behalf Of David Booth
> Sent: Sunday, July 12, 2009 7:25 PM
> To: Sean B. Palmer
> Cc: www-tag@...
> Subject: Proposed AWWW erratum on "information resources" [was Re: Fwd: Splitting vs. Interpreting]
>
> On Thu, 2009-06-18 at 17:34 +0100, Sean B. Palmer wrote:
> > 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?
>
> Okay, since you asked . . .  ;)  I'd suggest the following changes.
>
> 1. The first three paragraphs of section 2.2 currently read:
> http://www.w3.org/TR/webarch/#id-resources
> [[
> By design a URI identifies one resource. We do not limit the scope of
> what might be a resource. The term "resource" is used in a general sense
> for whatever might be identified by a URI. It is conventional on the
> hypertext Web to describe Web pages, images, product catalogs, etc. as
> “resources”. The distinguishing characteristic of these resources is
> that all of their essential characteristics can be conveyed in a
> message. We identify this set as “information resources.”
>
> This document is an example of an information resource. It consists of
> words and punctuation symbols and graphics and other artifacts that can
> be encoded, with varying degrees of fidelity, into a sequence of bits.
> There is nothing about the essential information content of this
> document that cannot in principle be transfered in a message. In the
> case of this document, the message payload is the representation of this
> document.
>
> However, our use of the term resource is intentionally more broad. Other
> things, such as cars and dogs (and, if you've printed this document on
> physical sheets of paper, the artifact that you are holding in your
> hand), are resources too. They are not information resources, however,
> because their essence is not information. Although it is possible to
> describe a great many things about a car or a dog in a sequence of bits,
> the sum of those things will invariably be an approximation of the
> essential character of the resource.
> ]]
>
> I suggest changing the above paragraphs to:
> [[
> By design a URI identifies one resource.  The term "resource" is used in
> a general sense for whatever might be identified by a URI.  We do not
> limit the scope of what might be a resource.  A resource could be
> anything that one may wish to identify --  physical, conceptual, real or
> imaginary.  
>
> An "information resource" is any resource that plays a role in the
> hypertext Web by producing "representations"[link to definition in sec
> 3.2] in response to Web requests.  Web pages, images, product catalogs
> and other things that are made available on the Web are all information
> resources.  Some information resources, such as static web pages, may
> change very little or not at all over time.  Others, such as one that
> displays the current weather report for Oaxaca, may vary frequently.
> Similarly, some information resources, such as an interactive travel
> booking site, may vary their representations depending on their
> requests.  Others, such as simple Web pages, may not.  Conceptually one
> can think of an information resource as a function from time and request
> to representation.
>
> Ambiguity of Resource Identity
>
> Although a URI is intended to identify one resource, and ambiguity about
> the identity of that resource should be avoided to the extent possible,
> ultimately ambiguity is in the eye -- or the application -- of the
> beholder.  Because anything can be a resource, what one party considers
> a single resource (perhaps having multiple aspects) another party making
> finer distinctions might consider multiple resources that should have
> distinct URIs.  
>
> For example, the content of a book may be placed on the web and
> identified by a particular URI.  Many parties will have no need to
> distinguish between the web page that provides the content of the book
> and the content of the book as an artistic work that is subject to
> copyright law.  Depending on one's perspective (or application) this may
> be viewed as a case in which the URI unambiguously identifies a resource
> that has multiple aspects or as a case of ambiguity, in which the
> artistic work and the web page are each deserving of their own distinct
> URIs.
>
> Resources whose essential characteristics can be conveyed in message are
> good candidates for being considered information resources.  Other
> things, such as cars and people are less good, because some applications
> are likely to find them ambiguous.  For example, if the same URI is used
> to directly identify both a person and a Web page -- an information
> resource -- an application that records the creation dates of people and
> Web pages may find this resource ambiguous, because it cannot
> distinguish between the creation date of the person and the creation
> date of the web page.  This ambiguity would be avoided by giving the
> person and the web page separate URIs.  On the other hand, the use of
> two separate URIs may impart a cost to other applications that have no
> need to distinguish between the person and the Web page, because it
> requires these applications to recognize two URIs that those
> applications consider equivalent.
> ]]
>
> 2. The current definition of "representation" reads:
> http://www.w3.org/TR/webarch/#internet-media-type
> [[
> 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".
> ]]
>
> I suggest changing this to:
> [[
> A representation is a response, from an information resource, that
> encodes information reflecting that information resource's state.
> Representations do not necessarily describe the information resource, or
> portray a likeness of the resource, or represent the resource in other
> senses of the word "represent".  Only an information resource can have
> representations in the sense used herein.
> ]]
>
> 3. In addition to the above changes, there are many instances of the
> word "resource" that should be changed to "information resource",
> because the context only applies to information resources -- not
> resources in general.  
>
>

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

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

[David Booth-6]

On Mon, 2009-07-13 at 11:32 -0400, Xiaoshu Wang wrote:
> David Booth wrote:
[ . . . ]

> > In some ways I agree, that it would be more appropriate to put the
> > material on ambiguity in a separate document on semantic web
> > architecture (which builds on web architecture, of course).  The reason
> > I included it here is that that is the only way I can see to explain
> > what's going on when someone uses the same URI for both a person and a
> > web page, and someone else complains that that creates an ambiguity.
> >  
> The word "ambiguity" is itself ambiguous without an explicitly specified
> ontological ground.  *Who * says, or *where* does it say, that it is
> ambiguous if a URI denotes both a person and a web page (what is a web
> page anyway)?  The semantics is, in fact, quite clear: the URI's
> referent is what it is -- a person and a web page.  

That is only clear to applications that have no need to distinguish
between the person and the web page.  But applications that need to
distinguish between them will find the referent ambiguous if it is both
a person and a web page.


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

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

[Xiaoshu Wang-3]

David Booth wrote:

> On Mon, 2009-07-13 at 11:32 -0400, Xiaoshu Wang wrote:
>  
>> David Booth wrote:
>>    
> [ . . . ]
>  
>>> In some ways I agree, that it would be more appropriate to put the
>>> material on ambiguity in a separate document on semantic web
>>> architecture (which builds on web architecture, of course).  The reason
>>> I included it here is that that is the only way I can see to explain
>>> what's going on when someone uses the same URI for both a person and a
>>> web page, and someone else complains that that creates an ambiguity.
>>>  
>>>      
>> The word "ambiguity" is itself ambiguous without an explicitly specified
>> ontological ground.  *Who * says, or *where* does it say, that it is
>> ambiguous if a URI denotes both a person and a web page (what is a web
>> page anyway)?  The semantics is, in fact, quite clear: the URI's
>> referent is what it is -- a person and a web page.  
>>    
>
> That is only clear to applications that have no need to distinguish
> between the person and the web page.  But applications that need to
> distinguish between them will find the referent ambiguous if it is both
> a person and a web page.
>
>
>  

Do you imply that some applications must be prohibited from running on
the Web? Or some opinions must be prohibited from expressed in the Web?  
If not, what is the point of this intended partition?

Xiaoshu

[Sean B. Palmer]

On Mon, Jul 13, 2009 at 3:48 PM, David Booth<david@...> wrote:

[On servers working in the way you described:]

> They all work in this way, though not necessarily using that
> terminology.  That's just the terminology chosen by AWWW
> to describe, at an abstract level, what happens.

Okay, so AWWW is an abstraction of web practice. You say that it's
describing what happens, so I presume you think that there's a high
degree of fidelity there? What makes you think that?

Can you not imagine different types or instances of abstractions that
have a higher degree of fidelity to current practice?

> Trying to change the terminology beyond that might be useful,
> but it would be a much bigger undertaking and is outside the
> scope of my suggestion.

If you want to correct the definition of "information resource", then
nothing's out of scope which deals with correcting that definition.
What if that's a bigger task than you think?

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