- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Fri, 11 Mar 2005 11:17:12 -0500
- To: "ext Tim Berners-Lee" <timbl@w3.org>
- Cc: public-www-archive@w3.org
On Mar 10, 2005, at 17:23, ext Tim Berners-Lee wrote:
>
> On Mar 10, 2005, at 13:48, Patrick Stickler wrote:
> [...]
> Though it may very well be that
>>
>> p:identifies owl:sameAs t:identifies .
>
> Well, you admit they differ in range, so they can't be the same.
Fair enough.
I was mostly wondering about whether they involve
the same sort of identification (i.e. denotation
per the RDF MT, vs. some other flavor of identification).
>
>>>
>>> Bear in mind, then, that in my architecture "t:identify"
>>> relates the URI to an Information Resource, which
>>> is an abstract concept you don't have in your architecture,
>>> a thing having meaning or abstract information content.
>>> Information Resources is a term I chose to define.
>>
>> The architecture I propose does not *exclude* information
>> resources. It simply does not rely on that concept. I think
>> it's good to clarify that point.
>>
>> It also occurs to me that where our use of the term "identify"
>> differs is simply in its permitted range. I.e.
>>
>> p:identifies rdfs:range rdf:Resource .
>> t:identifies rdfs:range t:InformationResource .
>>
>> Yet in both cases, we are talking about denotation per the
>> RDF MT.
>>
>> ???
>
> I think the point that I am making and you are missing is that
> before RDF was invented, URIs were defined for the web, and in
> that design they are used to stand for something.
>
> That is their sole purpose is to stand for something in web
> architecture. An RDF system based on URI + HTTP architecture
> can use that, leverage that, but if it uses a form of "denotation"
> where the URIs are linked to something different, then the
> same URI will denote something different in RDF and in HTTP,
> which is possible (Pat Hayes suggested it recently) but
> counter to the URI principle that each URI identify just one
> thing in all languages.
>
> This principle allows you in any language design to call out
> a URI as a symbol, and the design is that it does denote
> the same thing in each language where it is used.
I do in fact understand this point you are making.
But I'm not seeing the same result.
I.e., yes, perhaps originally folks used http: URIs
exclusively to identify documents (or information
resources), and those URIs should continue to identify
what they originally were intended to identify.
I'm not suggesting that the same URI be used to identify
two different things (which I consider to be a serious
error and garunteed to cause much trouble and grief).
But using some *other*, *new* http: URI that has never
before been used, to identify e.g. a car, does not
result in using that URI to identify two different
things.
Thus, this particular problem you seem to be seeing in
the p:identifies architecture simply does not exist.
Adopting the p:identifies architecture does not result
in a sudden ambiguity and mulitiplicity of identification
for existing http: URIs.
It simply means you can use http: URIs to identify other
things than informaton resources -- *if* you so choose.
>
>> [...]
>
>
>>>> PS: Consider that the http: web is a set of information objects
>>>> (streams of
>>>> bits) which are representations of resources (any resources).
>>>
>>> TBL: Ok, here your information object is a Representation: strictly,
>>> a stream of bits plus an Internet Content Type.
>>> I'll use a capital R for the class, whose definition which I think
>>> we agree about.
>>> (This is not InformationResource)
>>
>> PS: I take that to mean that we agree about what a Representation is
>> (a stream of bits).
>>
>
> Please don't say its a stream of bits. "Representation" in the HTTP
> spec and Roy's work and the AWWW
> includes the Internet Content Type.
>
>> (I see the Internet Content Type to be information about that
>> stream of bits, not an inherent part of the Representation itself,
>> since, after all, one stream of bytes can be interpreted validly
>> as corresponding to many different Internet Content Types)
>
> It is a fundamental part of the Representation, as the meaning of the
> message
> is determined by the pair of the ICT and the bits.
> It is important that the meaning of the message is defined by the
> Representation, with the common understanding of the stack of
> internet protocol specs, or you could never send email or
> publish a web page without some further out-of-band communication.
Are you saying then, that some stream of bits served as
text/plain is a distinct representation from a stream of bits
served as text/xml?
Interesting.
Well, OK. I can live with that. I think it's an odd distinction
to make, since it's still the same stream of bits, but I'm happy
to accept that.
In any case, it's not central to this particular issue, so probably
best to set it aside for now.
(sorry that I brought it up... my bad ;-)
>
>> [...]
>
>>>> Thus, the web consists of Representations which are linked together
>>>> due to the functionality of the HTTP protocol, such that, from one
>>>> representation, on may "traverse" to another representation.
>>>> Browsing
>>>> the web is simply jumping from representation to representation. Yet
>>>> the web machinery does not really care what those URIs acutally
>>>> p:identify.
>>>
>>> True.
>>> (However, it does care what the URIs t:identify)
>>
>> Why. I think that the web machinery only cares that one may interact
>> with representations given a particular URI, yet that interaction
>> is agnostic as to what the URI identifies (denotes).
>
> Hear I feel you are not listening to me, but just reiterating.
> We are arguing about what URIs denote. I say they denote
> what they t:identify. I say that that is different from what you
> say they p:identify. You propose that by t:identify I mean the
> same as you do by p:idenify but I DO NOT.
That's not what I'm saying.
What I'm saying is that the behavior of the web machinery does
not depend on what URIs identify, either t:identify or p:identify.
Yes, the HTTP specs and REST, etc. talk about URIs identifying
something, and that is true -- they do identify things -- but
the core, fundamental, and important behavior of the web really
actually does not depend on what those URIs identify -- only that
one is able to interact with representations of the thing identified,
and (for maximal usability) there is consistency in the experience
of accessing those representations.
I was simply trying to point out that neither t:identifies or
p:identifies is critical to the web functioning the way it
does every day, because no specific operation of any web server
or client depends on what a given URI *actually* identifies,
only that representations are consistently accessible via that
URI.
>
> You say that the WWW architecture does not care what a URI
> t:identifies.
>
> I say it does.
Please see above.
>
> Imagine an HTTP request.
> It is written in a langauge
> In that language the URI is a symbol.
> It means something.
> In HTTP, it denotes something.
Agreed thus far. (though HTTP doesn't depend on what
it denotes, even if HTTP says it denotes "something").
> How to know what it denotes? By finding out what is invariant for
> that URI.
No. That's simply not possible. Here's where we seem to butt heads.
I assert that it is absolutely *impossible* to know, based
on the nature and accessibility of representations, what a given
URI *actually* denotes.
One may guess correctly, but it will *always* be a guess. Always.
HTTP/REST may state that a URI identifies "something" but the web
machinery provides no means to either clearly express or reliably
determine what a given URI actually denotes. It's all left up
to speculation based on user experience.
Or are you saying that what the URI denotes is a set of representations?
(I can't imagine you are, because that is then a 3rd architecture...)
> In HTTP, what is invariant for a URI?
> What consistency is required?
> The consistency between the information content of the Representations
> returned.
> So URI is already tied to this in the HTTP architecture.
I follow what you are trying to say here. But I don't agree that
it is possible, no matter how much one analyzes all of the information
content of the Representations returned, to reliably determine what
the URI actually identifies -- i.e. even the poem versus a web page
about the poem.
Again, whether you use t:identifies or p:identifies there is an
inescapable ambiguity about the actual denoation of a any given
URI and t:identifies does not really buy you anything when it
comes to integrationg the web and semantic web.
You still need to be able to obtain, somewhere, explicit and formally
expressed information about the thing identified by a given URI.
Surely you don't expect semantic web agents to analyze a set of
Representations to try to determine if statements using that URI
as subject are talking about a poem versus a web page about the
poem??!
>
>
>> How do you see the web architecture (i.e. the protocols/models, not
>> human expectations) caring about what URIs identify (either
>> p:identify, t:identify, or denote per the RDF MT)?
>
> Suppose the symbol in the HTTP request was removed, or randomized.
> HTTP would not work.
> That shows that the web architecture cares about that symbol.
> It attached some significance to it.
That wasn't my question.
Let's say that a given URI is created to t:identify a poem. But
then later, the owner decides that he'd rather use it to identify
the web page about the poem and creates alot of RDF which describes
the web page -- yet the set of representations and the web
experience associated with that URI never chnages.
Well, to web users, nothing has happened. The fact that the URI
originally identified a poem, but then later identifies a web
page, is entirely *irrelevant* to the functioning of the web.
Web servers don't care. Web clients don't care. Human users don't care.
What a given URI actually denotes is entirely irrelevant to the
successful operation of the web.
>
>
>>>
>>>> The REST architecture essentially can be distilled into:
>>>> - you have a URI, it p:identifies "something" (and REST doesn't
>>>> care)
>>>> - you dereference the URI to get a p:representation of that
>>>> "something"
>>>
>>> I've added a p: on this relation, as in my architecture, the
>>> relationship
>>> is not between the IR and the Representation, not between the
>>> something and the
>>> Representation.
>>
>> Well, again, I don't see that the meaning of p:identifies and
>> t:identifies
>> is fundamentally different -- only its range of usage.
>
> You say that the WWW architecture doesn't care about p:identifies.
> I say it relies crucially on t:identifies.
> Therefore they are very different concepts.
See comments above.
>
>> Thus, if in this case, the "something" is an Information Resource,
>> then
>> p:identifies is functionally equivalent to t:identifies.
>
> This is the only way in which the the Web has been used to date,
> apart from your experiments.
(a) they are not experiements, they are deployed solutions
(b) they are not *my* solutions, they are shared by many, and
many arrived at those solutions long before I did.
> We should be true to that.
Well, SGML came before XML. Why not be "true" to SGML?
Are you saying that evolutionary progress is unacceptable,
regardless of the proven benefit?
> In other words, people do *not* just expect a representation on the
> planet neptune when they revisit a bookmark, they expect basically the
> same picture. That is how the web works.
NO! People expect *CONSISTENT BEHAVIOR* from bookmarks. People don't
care in the *least* what that bookmarked URI actually identifies.
And even if they *did* care, the web machinery CAN NOT TELL THEM!
Surely this is clear from years of Annotea and similar projects,
that users must guess at what the URIs mean and frequently disagree,
because they are left on their own to figure it out.
>
>> But if that "something" were e.g. the planet Neptune, then
>> p:identifies
>> would be OK to use, but t:identifies would have a range conflict.
>
> You are actually ignoring the web as a design when you use the URI
> to denote the planet in RDF.
> Because already real users all over the world expect the inforation
> content to be consistent, not just the subject of the page.
>
But the URI *can* identify the planet Neptune, and all representations
of the planet Neptune accessible via that URI perfectly consistent,
and users will be quite happy and satisfied with that.
Again, you seem to conclude all kinds of shortcomings of the
p:identifies
architecture which (a) are present also for the t:identifies
architecture
and (b) not introduced or increased in any way by the p:identifies
architecture.
It's hard to get down to the true core of this debate when you see
so many "phantoms" in the p:identifies archictecture which simply
do not exist.
>
>
>>>
>>>> - the representation of that "somthing" may refer to other
>>>> "somethings"
>>>> - one may utilize the links and the dereferencing process to move
>>>> from p:representation of "something" to a p:representation of
>>>> "someotherthing"
>>>> - at no time does REST care, nor is it relevant to REST
>>>> functionality
>>>> what "something" a given URI p:identifies
>>>> - users benefit when there is consistency in the nature of
>>>> representations
>>>> and their link-defined (indirect) relationships
>>>
>>> I think here you are saying that one requires some consistency in the
>>> mapping of a URI to a Representation.
>>
>> Absolutely. But not as a characteristic of the architecture.
>> Consistency
>> is simply a usabilty issue. My architecture (even yours I think)
>> doesn't
>> depend on consistency. You can have random representations served for
>> each request. But true utility and benefit are proportional to the
>> degree
>> of consistency in resolving URIs to representations in the same
>> context.
>>
>> Do you agree with that statement?
>
> That is where we absolutely and completely disagree.
> If random representations are served for each request, then the
> web is completely broken.
Firstly, no, the web would not be *broken* of representations
were served randomly. It would simply be useless. Yet you
would still be able to "surf the web" (i.e. move from representation
to representation via links).
That's a very important distinction, between being broken vs.
being useless (or less useful) and loss of that distinction is
I think tied up in our discussion. I see alot of your criticisms
regarding the p:identifies architecture relating to how you see
it providing less utility than the t:identifies architecture,
yet you present those criticisms as if p:identifies is actually
breaking the web (which it's not).
Secondly, I meant, do you agree with that last statement:
"... true utility and benefit are proportional to the degree
of consistency in resolving URIs to representations in the same
context."
> The architecture provides utility and benefit by requiring the
> consistency of representations.
I'd say then, that yes, you agree with the statement I meant.
Great.
> If you say "my architecture does not break but the web becomes
> unusable" then it is clear that your architecture is not capturing
> what makes the web work.
Well, (a) I think you misunderstood me to say that less consistency
is OK (which I did not say) and (b) I see the p:identifies architecture
as providing more utility, not less.
>
> If you want to move forward on this,
> to a point where we allow HTTP URIs to denote planets, you have
> to grant me that in current usage in the web architecture they do
> not,
If by "in the web architecture" you mean your t:identifies architecture,
then yes, I can agree that per that architectural model, http: URIs
should not be used to identify planets (though I won't say cannot,
since of course, you can't prevent folks from misbehaving).
But if by "in the web architecture" you mean "current web usage"
or "the web as we know and experience it today", then no, I'm
sorry, I can't grant you that point. Because there are many
current and longstanding examples of http: URIs being used
to identify resources such as planets.
> because that is not the invariant property of the Representations
> returned for a URI : the information content is.
Again, you are stating your view per the t:identifies architecture,
but I do not see how that particular point is clearly expressed
in the standards documents defining the web. I can, of course,
see how you might interpret those documents to reflect that
view, but I can also see how those documents could be reasonably
interpreted as compatible with the p:identifies view as well.
If those standards *were* in fact clear on this point, then this
debate would not have dragged on as long as it has. Eh?
>
>
>>> If you are saying something else, it is still true!
>>> If the mapping of URIs to Representation is randomized, then the
>>> web loses any usefulness.
>>
>> Right. But the web doesn't "break", from an architectural point of
>> view.
>
> It totally breaks.
You'd have to demonstrate that. I.e. show an application that ceases
to function properly because a URI is asserted to identify e.g. the
planet Neptune or a car, or ahem, an RDF property.
I think this debate has churned on far too long to not base its
resolution on hard evidence of impact (positive or negative) to
actual web solutions.
Otherwise, we just go round and round with a "angels on pin heads"
debate that never ends.
>
>
>>> However, the set of representations which one would expect to get
>>> from a URI
>>> can be big (and can change with time).
>>
>> Agreed.
>>
>>> My point is that the fundamental point on which the web depends is
>>> that
>>> the information content (in a Shannon sense) is the more or less
>>> same,
>>> or if not constant is a function which is clear to bother readers and
>>> writers (like the current front page of the Times).
>>
>> I agree, and see this as true for both architectures.
>>
>>> Here is where the InformationResource comes in.
>>> If you don't model that in the architecture, then you can't require
>>> or
>>> talk about the consistency which actually makes the web work.
>>
>> There I disagree. I think we can just as effectively talk about
>> consistency of representation, because the consistency has to
>> do with a consistency of user experience -- and there is a well
>> established and mature field of study addressing exactly such
>> usability issues, which does not succeed or fail on the existence
>> of some concept of "Information Resource".
>
> Actually, it does.
> Users tend to use the term "web page".
> They expect to get the same web page after going to a bookmark.
Or rather, they expect to have the same experience.
I'm sure that users in various contexts classify that experience
as other things than web page (query engine, bank summary,
music stream, etc. etc.)
I simply do not see how consistency of representation is
inextricably tied to the concept of either web page or
information resource.
And further advancements in the world of multimodal browsing
will further strain such a narrow basis for determining
consistency on the web.
It's all about experience, and expectations of consistent,
predictable experience.
On the web, it simply does not matter what the URIs identify.
>
>> I assert that it is straightforward to discuss consistency of
>> user experience as it pertains to the resolution of URIs to
>> representations without having to refer to a concept such as
>> "Information Resource", much less constrain the range of http:
>> URIs to such a class of resources.
>>
>> That said, I'm also not opposed to defining a class of "Information
>> Resources", if folks find such a concept useful.
>>
>> In fact, statements about consistency of user experience on the
>> web can honor both the generalized, unrestricted range of http:
>> URIs and the identification of Information Resources such that
>> it can be a useful and valid best practice such that:
>>
>> When an http: URI is used to identify a resource which is not
>> an Information Resource, resolution of that URI should employ
>> a redirection to another URI which identifies an Information
>> Resource
>> via which representations of the original resource can be accessed.
>>
>
>> or some such wording... but hopefully you get the point.
>>
>
> Yes. It has to be made clear.
>
> If we go along this path, then it would probably be best
> to use a new 3XX code, with machine-understandable meaning
> that the original URI refers to an arbitrary concept,
> and a human-readable error message in the body explaining to
> the human reader.
>
> I wonder what current browsers do with a new return code number
> which has a human-readable body.
Again (and again) I see no reason for a new 3xx code.
Because insofar as user expectations are concerned, having
an http: URI identify a planet, and then redirect to a URI
identifying a web page about that planet, will be just fine,
and the users won't even realize, or care, that the two
URIs identify different things.
But the semantic web agents *will* care. And redirection
need not be used for all MIME types such that for text/html
requests, the client is redirected to the web page, but
for application/rdf+xml requests, the client is provided
an RDF representation of the resource directly.
Thus, humans are oblivious to the use of http: URIs to
identify things such as planets, but semantic web
agents are able to get machine understandable representations
of resources (any resource) directly via the URIs identifying
them -- and (here's the good bit) with *no* change whatsoever
to the current globally deployed web infrastructure!
Nothing in the web machinery has to change to make this work.
>
>
>>>
>>>
>>>> Thus, if a URI p:identifies a car, and one dereferences that URI
>>>> and gets
>>>> a representation of the car, and that representation has a link
>>>> which
>>>> refers to the owner of the car, and one dereferences that URI and
>>>> gets a representation of the owner of the car, etc. etc. the fact
>>>> that the URIs p:identify the car and the owner (person) of the car
>>>> makes
>>>> no difference to the user experience.
>>>
>>> Yes. That is why p:identifies is not part of the Web architecture.
>>
>> Well, hey, that is the crux of this debate, right?
>>
>> p:identifies *is* a part of the architecture that I, and a wide range
>> of others, use every day, and with great success.
>
> Well, you and your hoards are very much extending web architecture
> into new ground.
Sigh... they are not *my* hoards, and these approaches were in use
long before I recognized the utility and benefit of them.
>
>>> From the point of view of the Web as an information space,
>>> p:identifies
>>> is not relevant.
>>
>> But neither is t:identifies IMO.
>
> I have argued above that it is crucial to the web architecture.
> If you like, the web, the information space, *is* at heart not more and
> no less than the t:identifies mapping.
And I would hope that my comments above have helped you
see that what a given http: URI identifies (either p:identifies
or t:identifies) is not critical to the success and functionality
of the web.
>
>> The web architecture as an information space simply uses URIs
>> as access keys irregardless of any higher level semantics we wish
>> to attribute to those URIs.
>
> t:identifies is not a higher level semantics.
> URIs are defined for the web.
> They are identifiers at that level.
URIs are used as indirect identifiers at the web level. I.e. the
web doesn't care what they identify, only that via those identifiers
representations can be accessed.
The actual identification is not relevant to the functioning of
the web.
> If you want to use them at a higher level then that is a change.
> It is a possible change.
> But it is a change.
I'm not suggesting any such change. I believe you have misunderstood
the point I was trying to make (and I probably stated it poorly).
> If you deny the use of URIs in the existing web architecture, we
> cannot make progress.
Of course I don't deny the use of URIs (and I would think that
would be clear, since this debate is all about *using* URIs).
> Because
>
>> *Humans* traditionally presume that those URIs identify something
>> (and often get confused or guess wrong about what the owner thinks)
>> but the web machinery itself doesn't care one way or another.
>>
>> The rub comes only now when we want to add the semantic web layer
>> atop the web layer and see that there is a gap, and there are two
>> (primary) views about how to bridge that gap.
>>
>> Both views appear to be coherent and self-consistent. But one view
>> would invalidate a broad range of successfully deployed and popular
>> applications
>
> DC: and FOAF: and friends. That is a problem.
They are the "poster children" of success for the semantic web!
If that is a problem, then the semantic web (as we know it) is doomed.
(though I don't think they are problems or the semantic web doomed)
> There are problems with this situation any way.
> It means that doe all the existing metadata on the web, we don't know
> whether it actually is talking about the web page it seems to be
> talking about.
> It could be redirected.
But that problem exists with your architecture as well.
>
> <http://example.org/foo> dc:author whitehouse:president .
>
> The subject could be a semantic redirect.
Whether resolution of that subject URI results in a redirect
has absolutely *nothing* to do with what it identifies.
> I don't know until I've tried it.
> I used to conclude from the form of the URI that
Whether you are able to determine by deferencing it, what
the URI identifies and the nature of the thing identified
is not central to either (a) whether the URI can identify
something like a planet or car or (b) whether representations
are consistently provided for that resource.
If you ask
GET /foo HTTP/1.1
Host: example.org
you may get back some HTML where you simply cannot know for
sure what that URI identifies or what kind of thing is identified.
But if you were to ask
GET /foo HTTP/1.1
Host: example.org
Accept: application/rdf+xml
or even
MGET /foo HTTP/1.1
Host: example.org
then you may very well get back some information about what the
URI identifies and what kind of thing it is.
>
>
>> I honestly see this httpRange-14 debate boiling down to which view
>> would be the least disruptive to adopt -- and I would hope you
>> would at least appreciate that the generalized, non-constrained view
>> results in the least pain insofar as re-tooling and rework of
>> solutions and methodology is concerned.
>
> Certainly it is the least pain for dc:title.
> But it does remove an architectural assumption about HTTP
> which has been generally correct.
I guess the issue is that assumption has not been held
universally (or even by a majority).
> Tempting to introduce another scheme name for the new stuff.
>
>>>
>>>> In each case, a user is moving
>>>> from representation (stream of bits) to representation, and the
>>>> utility
>>>> of those representations is not (for the web) really tied to what
>>>> those
>>>> URIs actually p:identify.
>>>
>>> Exactly.
>>
>> Lovely.
>>
>>>
>>>> Taking this view, neither cars nor poems are part of that web of
>>>> information objects, yet both are "on the web" because they can be
>>>> effectively described and related by information objects on the web.
>>>
>>> For your definition of "on the web", not mine.
>>
>> Fair enough.
>>
>>>
>>>> --
>>>>
>>>> 2. In section 2.1.2 you conclude (apparently) that if a URI
>>>> p:identifies
>>>> a car, then you have no URI to p:identify and refer to the web page.
>>>>
>>>> I fail, though, to see how you can come to that conclusion. I see
>>>> no reason
>>>> why one cannot have clear, unambiguous, and distinct URIs for both
>>>> the car
>>>> and the web page about the car, as well as for each representation,
>>>> and
>>>> use those distinct URIs effectively.
>>>>
>>>> And one can use redirection to share/reuse the same representations
>>>> amongst distinct resources. For example:
>>>>
>>>> http://example.com/aCar p:identifies a particular car
>>>> http://example.com/aCar.html p:identifies a web page about the car
>>>> http://example.com/aCar.jpg p:identifies an image of the car
>>>> http://example.com/aCar.rdf p:identifies an RDF description of
>>>> the car
>>>>
>>>> and redirection is used such that when one dereferences the
>>>> URI http://example.com/aCar, one is (by default) redirected to
>>>> http://example.com/aCar.html. If one uses content negotiation
>>>> and requests either a JPEG representation or RDF/XML
>>>> representation, they would be redirected accordingly to
>>>> http://examole.com/aCar.jpg or http://example.com/aCar.rdf,
>>>> etc.
>>>
>>> Ok, so you are saying that if one
>>>
>>> ?u1 http:RedirectTo302 ?u2
>>>
>>> That ?u1 and ?u2 can identify completely different levels of thing.
>>
>> Sure. Why not.
>>
>>> That could work.
>>
>> It *does* work. It's proven and used daily in numerous applications.
>>
>>> I don't like it, because I actually think that when HTTP is used in
>>> name
>>> server mode, for example, users are entitled to use the
>>> pre-direction URI
>>> as a valid URI for the web page.
>>
>> But that's not licensed by the HTTP spec. Clients, caches, etc. should
>> not presume that a 302 redirect is permanent, and it is clear that
>> all references to the original URI should remain unchanged.
>
> They are still expected to be identifiers for the same class of thing.
According to *your* architecture, but not according to the HTTP specs.
Please do not confuse that distinction. It is hard enough sifting
through this very challenging subject.
If I make a statement about or based on a particular specification,
then please address my statement in that context, otherwise this
discussion will very quickly degrade to the level of noise. OK?
>
>
>> (arguably, though, 303 would perhaps be better than 302, but I still
>> consider 302 to be just fine)
>>
>> That said, it really depends on what you mean by "a valid URI".
>>
>> The redirect implies a relationship between two resources, such
>> that they share representations -- and thus, one could "validly"
>> access representations of the first resource via the URI of
>> the second, but it would be careless, dangerous, and ill advised
>> to rely on the second URI as the primary means by which
>> representations of the resource identified by the first URI
>> would be regularly accessed.
>>
>> Hence the note in the HTTP spec not to take the redirect URI
>> as permanent.
>>
>> Again, see the description of
>>
>> http://sw.nokia.com/WebArch-1/resolvesAs
>>
>>
>>> In current web usage, the pre- and post- redirection URIs can be
>>> interchanged
>>> largely, and this idea that they p:identify totally different types
>>> of
>>> thing seems to revise history. But let's go along with it for now.
>>>
>>
>> I'm not convinced of that. But if enough folks are, we could
>> use 303 as a matter of "best practice" (or, even define yet another
>> redirect response code).
>>
>> But I see this as a minor side issue to the core of this debate,
>> not a flaw, per se, in the architecture I employ.
>>
>>>
>>>> Thus, there is an intersection between the representations
>>>> accessible for the car with those of the web page, image,
>>>> and RDF description; yet no ambiguity about which URI
>>>> p:identifies which resource, and no impact to the web
>>>> behavior, since dereferencing any of the above URIs results
>>>> on obtaining a suitable/reasonable representation.
>>>
>>> Well, when you say there is no ambiguity as to which
>>> URI p:identifies which resource, there is in the sense that an HTTP
>>> client cannot tell using existing protocols which URIs are supposed
>>> to p:identify cars and which are supposed to p:identify web pages.
>>
>> True, but that's true for both architectures. I could have more
>> correctly stated that avoidance of ambiguity is facilitated
>> by each distinct resource having a distinct URI such that each
>> can be referred to unambiguously.
>>
>> (and with solutions like URIQA, clients can achieve clarity
>> rather than being left to guess about the meaning of URIs)
>>
>>>
>>>> The representations themselves can also be p:identified by URI,
>>>> e.g. the server could assign urn:uuid: URIs to each, such that
>>>> one would then be able to make clear and unambiguous statements
>>>> about the car, the web page, the image, the RDF description,
>>>> and any actual representation (stream of bits) ever recieved when
>>>> dereferencing the URIs p:identifying those resources; including
>>>> the ability to talk about how representations change over time.
>>>
>>> Ummm ... giving the representations URIs yes is possible, and
>>> yes allows metadata to be given but no doesn't per se give you
>>> the way to give the types of the various things p:identified.
>>> But you could, then, with RDF, for example.
>>
>> Right. I.e. using URIQA or something similar.
>>
>> The point is that we can give all these distinct resources
>> distinct (http:) URIs and both describe them as well as
>> provide representations for them.
>>
>>>
>>>> Thus, using an http: URI to p:identify a car does not preclude being
>>>> able to refer unambiguously to a web page about the car. Those
>>>> are two distinct resources and as such deserve to be p:identified
>>>> by two distinct URIs. The important point is to be clear what
>>>> each particular URI actually p:identifies, and not be careless
>>>> or sloppy in guessing or presuming what it p:identifies based
>>>> simply by the nature of the representations accessible.
>>>
>>> Here is a major problem I have with the p:identifies architecture.
>>> You ask people not to make assumptions about what is p:identified.
>>> However, whenever a URI is quoted and people stick it in a web
>>> browser,
>>> and maybe bookmark it, they are using the architectural point
>>> that there will be an expected consistency of representations
>>> for that URI.
>>
>> Yes, but that is not incompatible with the p:identifies architecture.
>> In fact, such consistency is considered just as important.
>
> No.
Well, I guess if you're going to start calling me a liar (or incoherent)
we can just stop now.
I ASSERT THAT CONSISTENCY OF REPRESENTATIONS IS OF CRITICAL
IMPORTANCE TO THE USABILITY OF THE p:identifies ARCHITECTURE.
OK?
>
>>> And the consistency they expect on the web is,
>>> looking at it either as an engineering question, or
>>> more philosophically, is that the information content will
>>> be consistent.
>>
>> Yes, and again, I see no difference on this point between
>> the two architectures.
>
> There I can't help you any more. I have explained it above.
And I've explained why I see no difference.
So if we can't get past this point, then that's very unfortunate.
>
>>>
>>> Witness the fact that if you bookmark something (before or after
>>> redirection)
>>> and once you get back an HTML page and the next time a PNG of that
>>> page
>>> you are not upset. But if you bookmark a picture of a car
>>> (whose URI which you actually say p:identifies the car)
>>> and next day you get back the parts inventory of the car
>>> (also a valid representation of the car, but totally different
>>> information content)
>>> then the we user has just cause to be upset.
>>
>> Yes, but such inconsistent behavior is neither more likely
>> nor more tolerated by the p:identifies architecture.
>>
>> And such inconsistent behavior is neither less likely nor
>> less tolerated by the t:identifies architecture.
>
>> On this point, there simply is *no difference*.
>>
>
> Garbage. The t:identifies relationship to the Information resource
> is defined to describe that consistency which users do expect.
One can achieve, and model, that consistency of experience without
having to posit any concept of Information Resource or any constrained
range on http: URIs.
Here, I think, is the very root of this debate, perhaps.
You see a constrained range of http: URIs as garunteeing in some
way the consistency of user experience, yet I see any such garuntee
as an illusion and that URI owners are no less obligated to
embrace the best practice of consistency of experience and
work to realize that consistency regardless of whether
http: URIs can or should not identify cars.
Using an http: URI to identify a car does not immediately
and unavoidably result in an inconsistency of user experience.
It is up to the URI owner to provide consistent representation
no matter what the URI identifies. Period.
>
>
>>> So, I think t:identifies is essential to the web architecture
>>> and p:identifies is, as you point out, irrelevant.
>>>
>>
>> Again, I don't see any difference.
>>
>> The web machinery is just as indifferent to "Information Resources"
>> as it is to arbitrary resources insofar as what http: URIs actually
>> identify.
>
> Last attempt.
> The web is not just a server, its a protocol between agents.
Agreed. And the functioning of that protocol does not
depend on what URIs actually identify (t: or p:) only
that there is consistency of representation. Period.
> Suppose an agent whose information state is s1 performs
> an HTTP operation H with a given URI to get to the state s2.
> It then performs the same operation again soon after, to get to s3.
> s3 should be the same as s2.
>
> H H s1 = H s1
>
> In other words, the information retrieved a second time
> does not extend the client's information, because
> it is essentially the same information as it got the first time.
> Even if a different encoding etc was used.
Again, you continue to presume that the same degree of
consistency is non- or less easily attainable if the URI
identifies e.g. a car.
That is simply not the case.
And the same inconsistency that would cause havoc for the
above agent can occur just as easily, even if http: URIs are
constrained to identifying only Information Resources.
*------------------------------------------------------------
* The t:identifies architecture does not in any way ensure
* or facilitate more consistency of representation than
* the p:identifies architecture.
*------------------------------------------------------------
(I'm tempted to repeat that 10 times, but just re-read it
10 times for the same effect ;-)
Can we please stop debating consistency of representation,
since either architecture can be equally consistent or
inconsistent insofar as user experience is concerned?!
Thanks.
>
>
>> It really only matters at the semantic web layer, and whatever
>> solution
>> we adopt should be as broad and encompassing as the semantic web.
>>
>> I think the p:identifies architecture achieves that elegantly,
>> and is also a deployed and proven approach. If the web was to
>> crumble to dust because of the p:identifies architectural view,
>> it would have done so long ago, but it keeps on purring without
>> the least burp.
>>
>>>
>>>> (this is one of the key motivations for URIQA, to be able to
>>>> provide an efficient and reliable means to ask what a given
>>>> URI actually p:identifies, to allow URI owners to explicitly
>>>> and formally publish such information in a manner that
>>>> automated agents can utlize with no further knowledge than
>>>> the URI itself)
>>>
>>> Here you have had to extend the protocol to remove the ambiguity.
>>
>> Which you would have to do regardless, as the ambiguity is
>> just as acute with the t:identifies architecture.
>>
>>> It is a workable design. We could move the web to it.
>>> I don't like it because it specifically undermines use of the
>>> Semantic Web tools to talk about the existing web.
>>
>> ????
>>
>> I've found that it *empowers* semantic web tools, and that
>> dealing with RDF/XML instances, or 3rd party repositories
>> (eg. SPARQL servers) which must be known, as the foundational
>> means to interchange and discover knowledge to fail to meet
>> very substantial bootstrapping issues.
>>
>> Both RDF/XML instances and SPARQL are *VERY* important,
>> and not to be devalued in any way by the above statement.
>>
>> My point is that being able to ask the web authority for
>> an authoritative machine-processible description of a
>> specific resource identified by a specific URI is just
>> as fundamental and essential as being able to ask the
>> web authority for a representation of a resource via
>> its identifying URI.
>>
>> I see the web and semantic web as two sides of the same
>> coin, where that coin is the set of URIs identifying
>> resources and on one side, you have the traditional HTTP
>> machinery for interacting with representations, and on
>> the other hand you have URIQA for interacting with
>> descriptions -- and it is via those descriptions that
>> you identify and subsequently exploit more comprehensive
>> services such as SPARQL engines, etc.
>
> HTML builds upon HTTP, using it as it is, using the # operator.
> RDF does too, using the # operator.
I disagree that RDF builds anything regarding the # operator.
The # operator is irrelevant to RDF as all URIs are fully
opaque to the RDF MT.
Semantic web applications may utilize the functionality
of the web layer to obtain representations of resources
identified by URIs (with secondary access incurring alot
of cost), but accessing representations of resources is
entirely out of scope at the semantic web layer, IMO.
>
> Your architecture is different, and people have to implement an extra
> protocol, and invalidate assumptions they had made.
NO NO NO. Again, leave URIQA out of this. It is not central
to this debate.
And NO, people do *not* have to implement any new protocol,
or in fact any change whatsoever to HTTP to employ the
p:identifies approach.
It works perfectly with the web machinery as it is
presently deployed.
And no assumptions clearly and unambiguously licensed by
the *specs* need be invalidated.
>
>> But just as the web would not work if you had to first
>> know from where to ask for a representation given a
>> particular URI, likewise the semantic web will not
>> work (bootstrap) if you must first know where (e.g.
>> a given SPARQL server) to ask for a description of
>> the resource identified by that URI.
>
> Yes. - this is why the # works.
It works for certain use cases, but does not scale generally
to all identified use cases.
Just because a given solution works in one case does not
mean it should serve as the basis for a generalized solution.
>
>>> I wouldn't be able to use RDF to talk about the authors and
>>> dates of web pages, unless I had already used URIQA to determine that
>>> I was actually dealing with the URI of a web page, not a car.
>>
>> Exactly!
>>
>> But even with your architecture, the same kinds of ambiguity
>> exists. How can you know whether a URI idenitifies a poem,
>> a translation of a poem, a web page about the poem, etc.
>> etc. etc.
>
> If it has no # then it identifies the web page (which is a poem in
> your case).
> It identifies the Information Resource.
??? Are you saying then, that a poem is not an Information Resource?
According to my reading of AWWW it certainly is.
>
>> You seem to presume a lack of ambiguity with your architecture
>> that is present in mine -- yet both architectures face the
>> very same problem.
>
> No, mine is NOT ambiguous.
I've provided examples of how it is ambiguous, insofar
as which possible Information Resource a given URI might
identify. I see no reason to repeat those or offer other
examples.
Given an http: URI, even assuming the t:identifies architecture,
that same URI can be used to identify many different distinct
Information Resources, and the web client/user cannot determine,
with full clarity and correctness, which resource the URI
identifies -- based solely on an analysis of the representations
accessible via that URI.
The user might be able to guess correctly, and guess with a high
degree of confidence, but one can never truly *know* for sure.
>
>> URIQA is just as relevant, necessary, and beneficial for your
>> architecture!
>>
>>
>>>
>>> In other words, your architecture world work, as a new design.
>>> Could be an improvement. But it is not compatible with what's out
>>> there.
>>
>> On the contrary, it is exactly the fact that the p:identifies
>> architecture *is* compatible with "what's out there" as well as
>> all the new semantic web solutions being deployed that so many
>> folks prefer, and utilize, that architecture.
>>
>> Insofar as compatiblity with "what's out there", I think it's
>> a very fair comment to note that the t:identifies architecture
>> is in fact *not* compatible with numerous deployed solutions
>> that are "out there" (DC, RSS, XMP, Creative Commons, ...)
>>
>> If you really care about being compatible with "what's out there"...
>
> dc: maybe a lot of the semantic web but it is a small part of the web.
> But I agree that it is a large deployment to be respected, and so
> we have to do something about it.
> But that doesn't mean we have to make everyone implement URIQA.
>
Sigh. This debate is *NOT* about URIQA!
And URIQA is *NOT* the motivation or justification for the p:identifies
architectural viewpoint, which predates URIQA by years.
If you are hung up about URIQA, then we'll not manage to move
forward with the real debate at the core of httpRange-14.
Let's not mention URIQA again in this discussion, OK?
(I really, really, really regret having ever mentioned it in
the first place if it constitutes such a hiderence to actual
discussion of the real issue)
>
>>
>>>
>>>> --
>>>>
>>>> 3. In section 2.2.2 you discuss the approach of using redirection
>>>> whereby when dereferencing a URI p:identifying e.g. a car the client
>>>> would be (perhaps with multiple hops) redirected to another URI
>>>> which p:identifies an information resource that would ultimately
>>>> result in obtaining a representation. Fine. That is in fact the
>>>> approach that much (even most) of the community uses (those who
>>>> use http: URIs to p:identify resources such as cars).
>>>
>>> Well, there are not a lot of people i have come across using the
>>> URIQA
>>> architecture. I do know DC does a redirect. I don't know a lot of
>>> reasoning systems which use it automatically.
>>
>> The redirection approach has nothing whatsoever to do with URIQA,
>> no more so that Flash or WebDAV or SOAP or any other technology
>> would have to do with redirection.
>>
>> Yes, we at Nokia redirect alot of requests to a URIQA server,
>> but that's a local solution (a good one, and one folks are
>> invited/encouraged to consider) but only one of countless
>> options for this redirection approach.
>>
>> The key is that representations of any resource can be served
>> with a minimal amount of burden insofar as management of
>> actual representations is concerned, as multiple resources
>> can (via redirection) share a common set of representations.
>>
>>>
>>> I do know lots of ontologies where you can get useful reusable
>>> information
>>> by dereferencing the document x which defines the terms for the form
>>> x#y.
>>>
>>
>> Sigh....
>>
>> I really, really don't want to go into the gory details of
>> all the scalability/bandwith issues that one is faced by
>> having to deal with secondary access via fragment identifies.
>>
>> I've posted more than enough information about this to the TAG list.
>>
>> Yes, you can do it. Yes, it can work in certain applications. And
>> yes, it is even compatible and acceptable with the p:identifies
>> architecture -- but it does not scale up to very large documents
>
> true
>
>> and does not scale down to limited capability devices (which
>> have limited ability to process arbitrary MIME types to properly
>> interpret fragement identifiers according to the MIME type).
>
> ?Eh? To be able to parse RDF/XML and useful for the semantic
> web just as you need HTML for the hypertext web. Not arbitrary types.
This issue is not specific to the semantic web, or RDF/XML, however
much it is relevant to the semantic web. It is much more general.
If a mobile web client (not semantic web agent) wishes to obtain
a represenation (e.g. for presentation to a human user) of a
resource identified by a URIref with fragment identifier, then
there is a scalability issue.
It also precludes being able to use content negotiation and
device optimization on representations specific to the
resource in question -- provided by the server, based on
operations on the server side.
Yes, the mobile client could ask for a particular MIME type of
the base document, but it may not have the capacity to process
and extract that complete base document, regardless of MIME
type, to present the specific information in question.
>
>> In short, if mobile applications are limited to secondary
>> access to representations of non-information-resources, it
>> will *substantially* reduce the utility of the web infrastructure
>> for mobile applications -- possibly to the point of Nokia
>> looking at other alternatives for mobile information interchange
>> than directly via the web.
>>
>> It's that serious a problem. If you have not reached clarity
>> about these scalability/bandwith issues, I encourage you to
>> revisit the TAG mailing list archives and re-read my posts
>> on this topic.
>
> I am aware of the problems for example with wordnet.
> Most ontologies, however, can be
>
>>
>>>
>>>> A distinct redirect response for such cases, such as 343, is not
>>>> however necessary. The present semantics of 302 is, I think, quite
>>>> sufficient, equating to "representations for the resource
>>>> p:identified
>>>> by the request URI can be accessed via this alternate URI". No
>>>> equivalence between the resources p:identified by the request URI
>>>> and the redirect URI are to be presumed. All that can be inferred
>>>> is that these two resources share some number of representations.
>>>>
>>>> Both DC and Nokia (and I'm sure many others) use this approach
>>>> with great success.
>>>
>>> I don't think the DC users actually dereference the URIs at all
>>> in the course of automated processing.
>>
>> Whether they do or not is irrelevant.
>>
>> The fact is that one can dereference a DC property URI
>> and access representations of that resource -- without
>> recourse to *anything* but the core web machinery.
>>
>> That is *hugely* powerful and useful functionality.
>>
>
> It doesn't distinguish the arcitectures.
???
That functionality is not provided (or acceptable) to
the t:identifies architecture, so the fact that it *is*
acceptable to the p:identifies architecture certainly
distinguishes the two architectures.
t:identifies -> can't (or shouldn't) do it
p:identifies -> no problem, go for it
>
>> You are going to be very hard pressed to convince folks who
>> appreciate just how powerful and useful that is to give it up.
>>
>
> Eh ... duh? If they just ahd a "#" in the namespace it world
> work just as well, and so would a bunch of other things.
Like I said, you're going to be hard pressed...
(i.e. alot of folks are simply not the least bit convinced that
'#' is a magic bullet that will solve many of their woes, but
in fact will rather increase them in very critical areas)
>
>>>
>>>> C.f. http://sw.nokia.com/WebArch-1/resolvesAs
>>>>
>>>
>>> (cwm http://sw.nokia.com/WebArch-1/resolvesAs
>>> doesn't parse it as it seems to return text/html when
>>> cwm *should* be asking it for rdf/xml and/or N3.
>>> But it could. And then cwm --closure=p
>>> http://www.w3.org/2000/10/swap/test/uriqa/t1
>>> would work too maybe or something like it)
>>
>> Right. The default representation is for humans, and
>> is presented as HTML.
>>
>> And you could, ahem, also just have cwm ask
>>
>> MGET /WebARch-1/resolvesAs HTTP/1.1
>> Host: sw.nokia.com
>>
>> e.g.
>>
>> curl -X MGET "http://sw.nokia.com/WebArch-1/resolvesAs"
>>
>> ;-)
>
>
> I kinda rest my case.
> You want me to retrospectively change my web client so that the web
> now is not just the maping from URI into Represntation, but now
> the pair of that mapping and an MGET mapping wich we will all have to
> write.
No, no, no. It is no more obligatory than support for a particular
MIME type by a particular browser is "obligatory". Those who see
benefit, will consider exploiting such a solution. But again,
this debate is not about URIQA, so just move on past this point.
> So far, the semantic web is building on top of the single-layer single
> web,
And with p:identifies it will continue to be so.
> with no
>
>
>>
>>>
>>>
>>>> (note also that the above URI p:identifies a property, and
>>>> dereferencing it results in redirection to a web page
>>>> describing that property -- i.e. a representation of the
>>>> property, and the web page)
>>>
>>> In fact, a p:representation of the Property, and a t:representation
>>> of the
>>> web page.
>>
>> I don't see the difference. Unless you are also positing that
>> only Information Resources can have representations. I.e.
>>
>> p:representation rdfs:domain rdf:Resource .
>> t:representation rdfs:domain t:InformationResource .
>>
>> ???
>>
>>>
>>> Yes, I see that this could work. I just think it is squatting on
>>> existing WWW architecture in an inappropriate way.
>>
>> Well, I guess the core of this debate is about convincing folks
>> of that point.
>
> Yes, or shifting the WWW architecture to make it seem more appropriate.
>
>> I see it as correctly and effectively utilizing
>> the existing web architecture.
>>
>
> MGET is not existing architecture
Sigh.
I was not talking about MGET or URIQA. I was stating that
using http: URIs to identify things such as cars and serving
representations of those things is an effective and IMO
acceptable use of the existing web infrastructure.
>
>
>>>
>>>> --
>>>>
>>>> 4. In section 2.2.2 (and elsewhere) you seem to suggest that using
>>>> http: URIs to p:identify e.g. cars introduces an ambiguity and
>>>> usability
>>>> problem for those wishing to annotate/describe/refer to web pages,
>>>> such that they will be unnable to or unsure of how to refer
>>>> accurately to the resource in question (your specific example
>>>> referred to ambiguity between a web page about the Vietnam war
>>>> vs. the Vietnam war).
>>>
>>> Yes.
>>>
>>>> Yet, in fact, this form of ambiguity has existed since the
>>>> very beginning of the web, such that there is no clear way
>>>> to determine whether a given URI p:identifies some abstract
>>>> information resource, a particular form of expression of
>>>> that information resource, or a specific representation of
>>>> that resource.
>>>
>>> However, there is a consistency for t:identifies.
>>
>> I don't see how you have demonstrated this. You have frequently
>> asserted this, but have not actually provided any motivating
>> arguments.
>>
>
> I have above. If you don't get them, then I give up.
> It is the fundamental relation in web architecture.
I guess that's at the core of this debate.
I feel I've clearly presented how it is not fundamental to
existing web *behavior* and experienced *functionality*. It
may be fundamental to *your* architecture, but it is not
critical to how the web works day-in-and-day-out.
>
>>> Hence the superiority of the relation for describing web
>>> architecture.
>>
>> Again, you are basing this conclusion on a premise that you
>> have not proven.
>>
>> I consider that premise to be false, and thus disagree with
>> your conclusion.
>>
>>>
>>>> E.g. if one has the URI http://example.com/myCar
>>>>
>>>> which resolves to the following text/html encoded data stream
>>>>
>>>> [
>>>> <html>
>>>> <body>
>>>> <pre>
>>>> My car.
>>>> It is blue.
>>>> When I am not in it,
>>>> I am blue too.
>>>> </pre>
>>>> </body>
>>>> </html>
>>>> ]
>>>>
>>>> Assuming, for the sake of discussion, your position that the
>>>> URI http://example.com/myCar must p:identify an information
>>>> resource and thus we can exclude it t:identifying a car,
>>>
>>> (thank you!) we exclude it from t:identifying a car certainly.
>>>
>>>> how is a
>>>> user to know if that URI t:identifies
>>>>
>>>> (a) a poem about a car (the abstract body of information)
>>>> (b) a particular edition of the poem, with particular line breaks
>>>> (c) a particular translation of the poem (e.g. in English)
>>>
>>> Good point. However, I would point out that
>>> these are all in a sense "a poem", just a poem specified
>>> more or less generically. I think generic t:identification
>>> is really important.
>>> http://www.w3.org/DesignIsses/Generic
>>>
>>> For answer, well, you'll find on w3C tech reports a list of the URIs
>>> and which they are (latest version, this version, etc).
>>> You'll also find links in blogs and online magazine to
>>> a persistent link for a given article rather than the time-varying
>>> "current" one.
>>> You'll see little flags linking to different languages, etc.
>>
>> Fair enough. But the question is about a specific URI, and
>> how, knowing only that URI, do you disambiguate between the
>> many possible information resources it could identify.
>>
>> I.e. the problem of ambiguity is just as acute with your
>> architecture -- its scope is simply more constrained because
>> the set of possible resources which are information resources
>> is a subset of all possible resources -- but the problem
>> is *identical* and just as significant.
>>
>>>
>>>
>>>> (d) a web page containing a poem
>>>
>>> I don't think that the distinction here is fine.
>>> I would be more inclined to say that the document is a poem,
>>> and it is a web page. This web page is a poem about a car.
>>> There is no level difference, certainly nothing worth extracting
>>> in the architecture.
>>
>> I disagree. I see a level distinction between the
>> poem and a web page via which the poem is communicated.
>>
>> And here is the rub: the definition of what is or is not
>> an Information Resource is slippery at best. I've asked the
>> TAG to provide even a short list of "typical" examples,
>> and I expect that producing even a list of a dozen
>> examples of "typical" information resources would be an
>> exercise in futility. Because folks will disagree about
>> degree. Because the conceptual distinction is too fuzzy,
>> and the boundry between Information Resources and non
>> Information Resources too imprecise.
>>
>> And thus, it is not possible to base an architectural
>> distinction on such an imprecise classification.
>>
>> That doesn't mean such a classification can't be useful,
>> but it will always be a matter of debate whether some
>> resource X is or is not a valid information resource.
>>
>>>
>>>> (e) an HTML encoding of a web page containing a poem
>>>
>>> That is *not* identified. The architecture does not have to give a
>>> URI
>>> for everything under the hood.
>>
>> Agreed. The *architecture* does not *have* to, but it should *allow*
>> it.
>>
>>> The HTML encoding is
>>> an octet stream
>>
>> Really? I was thinking about the abstraction, such as might
>> be processed by a DOM API or XSLT script (let's say XHTML
>> rather than HTML, for the sake of discussion).
>>
>> A particular HTML instance could be serialized in multiple
>> distinct octet streams yet still constitute the very same
>> document.
>>
>> But again, such debates are irrelevant given the p:identifies
>> architecture. Identify whatever you like, and (ideally) say
>> what the URI identifies.
>>
>> And let OWL reasoners deal with the social disagreement and
>> resulting contradictions ;-)
>>
>>> which, when paired with the content type "text/html",
>>> forms a t:representation of the poem. Neither the representation or
>>> the octect stream nor the HTTP response noe the HTTP transaction are
>>> given
>>> a URI in general, and certainly not that URI.
>>>
>>
>> Why not? If I say that
>>
>> http://example.com/myCar rdf:type p:HTMLInstance .
>>
>> and always return the same text/html encoded octet stream as a
>> representation,
>> I see no architectural problems.
>>
>> I'm clear about what my URI identifies, and I consistently serve
>> a valid representation.
>>
>> I just don't see where there is an *architectural* issue there.
>>
>> There might be a *philosophical* issue, or an issue of style or
>> methodology, but the bottom line is that *nothing breaks* and
>> it is clear to users (humans or machines) what I mean by that
>> URI and what information I associate/publish via that URI.
>>
>> I see that as the web working very affectively.
>>
>>>
>>>> (f) some other information resource
>>>
>>> The web replies on it *not* being a different one.
>>
>> ???
>>
>>> If I see the poem and sent you the URI, I generally expect you to
>>> see the poem.
>>
>> Yes, per the principle of consistent behavior, you would
>> expect me to have the same experience as you.
>>
>> I agree.
>>
>>> You must be able to use the name of the thing for the thing.
>>
>> Sure.
>>
>>> I don't expect you to get a different poem.
>>
>> Or perhaps, you don't expect me to have a different web experience.
>>
>
> Experience Schexperience.
> I expect you to get the same information.
And if a given body of information (an Information Resource) is
at the center of that intended experience, then yes, I will
recieve the same *essential* information.
But depending on contexts, our experience may differ, and so
might the actual information we recieve.
Again, this is true for either the p: or t: architecture.
>
>>> I don't expect you to get a different resource (say a picture) or
>>> the same thing
>>> because the server has deemed that the URI p:identifies something and
>>> both Representations are p:representations of that thing.
>>
>> Why not? Perhaps the representation *you* recieved was a Flash
>> animation of the poem, which presented each line in a timed
>> sequence, with pauses in between and some nice background
>> music. But I am browsing the web on my phone, and so I
>> recieve an XHTML MP encoded representation which is fairly
>> basic, but efficient.
>
> A flash animation of the poem is the same poem!
I would say that the flash animation is not exactly
the same resource as the poem itself. Yes, the flash
animation embodies the poem, but it is not the poem.
> Do the information test. H H s == H s.
> If the operation is idempotent in that way,
> if I am not further enlightened by the phone message because
> I have already seen the flash version, then the two representations
> are doing a good job of conveying the same information.
I appreciate your point, but I don't see it as critical
to the web architecture. Meaning, what is essential here
is that the experience (or for your sake, the essential
body of information) is the same.
Yet that consistency has nothing whatsoever to do with
whether the URI in question identifies a poem or a
web page about the poem (or a car or a web page about
the car) -- but about the care and effort the owner
of the URI has put into ensuring consistency of
representation so that we both derive sufficiently
similar information (experience).
Again, consistency of representation is neither
provided by the t: architecture nor lessened or
precluded by the p: architecture.
>
>> In no way do either of us, given either the debated
>> architectures, know what the URI actual identifies.
>>
>> What counts is that our experience -- across all variability
>> of representation, is sufficiently consistent (according to
>> the goals/wishes of the URI owner) such that our experiences are
>> similarly meaningful (according to the goals/wishes of the
>> URI owner).
>>
>
> You can be more concrete when yo talk about information.
> Especially on the semantic web.
>
>> You may have simply said to me: "Nice, eh?" and I was left
>> wondering what the heck you were taking about. The poem?
>> The animation (which I can't see). The music (which I can't
>> hear). The choice of font (which may or may not be the
>> same for both of us). The total overall experience (which is
>> not exact for both of us).
>>
>> You are touching on usability issues that extend far, far
>> beyond the boundries of this particular debate and which
>> are issues of equal siginficiance for *both* architectures.
>>
>> These are not issues introduced or exacerbated by the
>> p:identifies architecture -- and I would strongly argue
>> that the p:identifies architecture more cleanly fits with
>> solutions such as URIQA which *do* help to address these
>> kinds of usability an social meaning issues.
>>
>>>
>>>> ???
>>>>
>>>> All of the above options are compatible with your view.
>>>
>>> Well, no I have gone over them above.
>>>
>>>> Yet
>>>> some user wishing to e.g. use Annotea or make RDF assertions
>>>> pertaining to whatever it is they are experiencing when
>>>> dereferencing that URI cannot be clear about what they are
>>>> acutally talking about, even if http: URIs are constrained
>>>> to p:identify "information resources".
>>>
>>> When users annotate things with human language, they are not
>>> semantic web engines. In natural language, it its quite
>>> normal to convert between levels implicitly. This
>>> is not a guide for the architecture.
>>
>> My point is that ambiguity between possible Information Resources
>> identified by a given URI is just as acute a problem as ambiguity
>> between possible resources of any kind identified by a given URI.
>>
>> Your architecture does not preclude or alleviate this ambiguity,
>> which is what I understood you to be suggesting.
>>
>>>
>>>> If one were to make a recommendation (or warning) based on
>>>> the user experience of dereferencing that URI, they still
>>>> would have no way of doing so unambiguously.
>>>>
>>>> This is because the web/REST architecture simply doesn't
>>>> care what the URIs actually p:identify, or need to care,
>>>> because it works just fine serving representations via
>>>> URIs irregardless of what those URIs p:identify.
>>>
>>>
>>> However, it really depends on consistency in what they t:identify.
>>
>> I just don't understand what you mean by that statement.
>>
>> Again, you seem to be suggesting that t:identify has no
>> such ambiguity. I assert (and think I've demonstrated)
>> that it does.
>>
>> Perhaps we're just talking past one another on this point.
>>
>> ???
>
>
> I suspect so. Thanks for trying.
Well, it's a pity if we cannot make progress in this discussion.
I think it has been in any case a useful and meaningful interchange,
even if we didn't fully match wavelengths on all points.
Maybe what each of us has shared will ferment in our subconscious
and make sense at some future time.
Cheers,
Patrick
>
>>
>>>
>>>> There is no fundamental difference between the ambiguity
>>>> "poem or web page about poem" versus "car or web page about car".
>>>
>>> That wasn't a web page *about* a poem, it was a web page which was a
>>> poem.
>>
>> How the heck to *you* know. How does anyone know? You *can't*
>> based on the URI alone, or by desciphering any representations
>> accessible via that URI.
>>
>> It *could* identify a web page about a poem, if that's what
>> the URI owner thinks it identifies.
>>
>> And both a poem and a web page about a poem are distinct
>> Information Resources -- therefore http: URIs constrained
>> to only indentify Information Resources are still ambiguous.
>>
>>
>>> Let us not split hairs as to what we mean by "web page".
>>> But note that giving a poem in a different font or different
>>> character encoding
>>> is a whole lot different from the 'about" relationship between a
>>> subject
>>> of a document and the document.
>>
>> It is only a difference of degree, and folks will
>> debate ad nauseum about where lines should be drawn
>> along that continuum.
>>
>> The p:identifies architecture alleviates any necessity
>> to have that debate, insofar as the architecture is
>> concerned.
>>
>> The t:identifies architecture will have to live with an
>> endless debate about the nature and membership of the class of
>> Information Resources.
>>
>>>
>>>
>>>> The web architecture simply does not provide the machinery
>>>> to be clear about what URIs p:identify. That's why we need
>>>> the semantic web (and IMO why we need solutions such
>>>> as URIQA).
>>>
>>> Certainly to use p:identify, you have a good argument for needing
>>> something extra, perhaps URIQA.
>>
>> And, as I hope I've clarified, for t:identify as well.
>>
>>>
>>> But the web architecture already requires a concept of t:identify.
>>> I argue that you can't mess with that.
>>
>> I just don't see how it is essential (or that I've understood
>> what you really mean by that).
>>
>>>
>>> You don't *have* to mess wit hit is you use the time-honored way
>>> of identifying them by the document in which they are defined.
>>> Like "US citizen for the purposes of article 1234 of the Act".
>>> It maybe clumsy for a few pathological cases like wordnet,
>>> and we may have foaf: and dc: which we would have to transition.
>>
>> I'm not sure you grasp just how disruptive, and unrealistic
>> such a "transition" would be.
>>
>> Prediction: it will never happen. And trying to force it will
>> be the beginning of the end of the semantic web as we know it.
>>
>>>
>>> So maybe we need some sort of compromise.
>>> A new HTTP redirect could separate the distinction between
>>> a document and its subject from that between a generic document and
>>> a specific one.
>>
>> What about a redirect from a non-information resource
>> to another non-information resource.
>>
>> I.e. a URI identifying the planet neptune redirects
>> to a URI identifying an image of the planet neptune
>> which redirects to a URI identifying a particular
>> scaling and resolution of that image which eventually
>> gets served as a JPEG encoded stream of bits.
>>
>> 302 works fine for all of that. What's broken? And
>> again, how do you reliably and without confusion
>> decide when to use 302 or your new redirect?
>>
>>> DC and FOAF could be fitted out with that.
>>> It could maybe be made into something more general along the lines
>>> of "I can't just give you a t:representation of that, but here is
>>> something which tells you about it and how to access it".
>>
>> Hmmm.... I would say that a 302 does not mean "I can't give you
>> a representation" but rather "I can't *directly* give you a
>> representation, but you can access a representation via this
>> other URI".
>>
>>> For example "that is a huge document -- suggest you query it with
>>> sparql"
>>
>> ???
>>
>> What is a huge document?
>>
>> Query it with SPARQL where?
>>
>> Why be tied to a particular (albeit execellent) solution?
>>
>> Why not a relational database, why not a perl-cgi script,
>> why not a static representation?
>>
>> You are needlessly limiting the range of possible solutions.
>>
>> The success of the web is because it is simple and decentralized,
>> and clients need a minimal amount of special knowledge to get
>> achieve a substantial amount of functionality.
>>
>> You are hobbling the semantic web by forcing centralized, specific
>> solutions.
>>
>> The generalized architecture leaves it just as free and open
>> to users to decide how *they* wish to provide access to
>> representations
>> of resources identified by *their* URIs.
>>
>> - A URI identifies a resource. Any resource. Period.
>>
>> - The owner of the URI decides how to server representations of
>> that resource.
>>
>> - Redirection is a useful way to minimize the overhead of
>> representation
>> management (for either architecture).
>>
>> - URI owners may choose to use SPARQL, or URIQA, or WebDAV, or
>> MySQL,
>> or any of countless tools and solutions (existing or still to
>> appear)
>> to serve representations *as they choose*. The (p:identifies)
>> architecture
>> does not care. It neither constrains nor favors any approach.
>> There is
>> total and complete freedom for URI owners to decide however they
>> want
>> to serve representations -- *including* e.g. redirection to a
>> URIref
>> with fragment identifier!
>>
>>
>>> or "that is an abstract concept, definitive ontology is in this
>>> file".
>>>
>>>> --
>>>>
>>>> 4. You have often stated, in various forms and at various
>>>> times, as you do in this document, "that wasn't the model I
>>>> had when URIs were invented and HTTP was written".
>>>>
>>>> OK. Fair enough. We should certainly give strong value to
>>>> original design considerations and be very hesitant to
>>>> question and/or diverge from them.
>>>>
>>>> Yet, is it not reasonable to consider that perhaps a very large
>>>> and diverse segment of the web community have all noticed and
>>>> beneficially exploited a fairly intuitive generalization of
>>>> the original design and usage of http: URI in order to substantially
>>>> broaden the scope and coverage of the web? and have done so
>>>> in a way that maximizes the benefit of a globally deployed
>>>> and proven infrastructure without negatively impacting
>>>> (or substantially impacting at all) the user experience
>>>> traditionally associated with the web?
>>>
>>> While I think many people have done the normal human thing and
>>> used rather interchangeably in language documents and the things
>>> they describe and their URIs - this is normal - I think you are
>>> misleading if you mean to suggest that many people apart from you
>>> are building semantic web things which work using the URUQA
>>> architecture.
>>
>> That's not what I meant at all. In fact, I regret having
>> even mentioned URIQA since (a) it is not directly relevant
>> to this discussion and (b) the arguments for the p:identifies
>> architecture are far broader and fundamental than that particular
>> tool.
>>
>> Yes, URIQA nicely demonstrates the benefits of the p:identifies
>> architecture, and presumes that architecture, but this is not
>> an argument for URIQA, and if URIQA did not exist, I would still
>> be arguing the very same position.
>>
>> And per your comment above, I meant to state that there are many
>> folks using the p:identifies architecture (not URIQA) very
>> effectively.
>>
>>> And I don't think you address the expectation among web users and
>>> application
>>> designers for the architectural constraint of consistency
>>> of information content as a function of URI.
>>
>> 1. I think I've addressed it repeatedly, both in this interchange
>> as well as in numerous posts to the TAG and elsewhere. I'm a
>> strong proponent of consistent user experience, and as I note
>> above, the issue of consistent user experience is not significant
>> to this debate as it is (or should be) equally embraced by both
>> (all) competing web architectures.
>>
>> 2. You seem to presume that the t:identifies architecture somehow
>> ensures or at least increases, by some mystical (to me) manner,
>> the consistency of user experience -- yet the t:identifies
>> web can be just as inconsistent.
>>
>>>
>>> In a way this expectation is so obvious that it goes without saying.
>>
>> And as I agree with this expectation, and that both architectures
>> should, and do, embrace it, let's go without saying anything further
>> on this particular point ;-)
>>
>>>
>>>> With rare exceptions, I think it is fair to say that those
>>>> using http: URIs to p:identify cars, properties, people, etc.
>>>> are not acting carelessly or with disregard to the tradition,
>>>> history, and standards-grounded definition of the web. Most
>>>> of these folks have thought long and hard about why they
>>>> chose the approach they did -- many suffering (and continuing
>>>> to suffer) angst over the potential, real, or percieved
>>>> conflict with your original conception. Yet the benefits
>>>> are sufficiently great to motivate increasingly wide
>>>> adoption of this more generalized view.
>>>
>>> I grant you that from the semantic web point of view it
>>> is much nicer to just use the HTTP space wiht gay abandon.
>>> And clearly a possibility would be to make a new
>>> HTTP-like space (a bit like Larry's tdb: space, That Defined By,
>>> or maybe a completely separate protocol)
>>> which has the sort of properties you describe.
>>> Documents in fact could then be just be concepts in the web,
>>> and asking about them would return one or more representatations
>>> just expressed in RDF instead of HTTP. The whole protocol on
>>> the wire could in fact be RDF.
>>
>> Yet this is unnecessary. One web is enough, and it works
>> just fine using the p:identifies architecture.
>>
>> I've long asked for you or anyone to present any evidence of
>> how the p:identifies architecture actually causes somethine
>> to *break* or in any way is detrimental, in practice, to any
>> specific application and I've never seen any form of response
>> that I could recognize as meeting that challenge.
>>
>> That challenge remains.
>>
>> I'm a very practical guy. I'm very much swayed by hard evidence.
>>
>> All the evidence I can see simply proves that the p:identifies
>> architecture is (a) useful, (b) efficient, (c) reliable,
>> (d) quite intuitive, and (e) successful -- with no negative
>> impact to any existing web application.
>>
>>
>>>
>>> Given the fact that daap: servers and so on sprout across the net
>>> an great speed, maybe that would not be such a stupid idea
>>> for a semantic web space first and foremost.
>>> web2:2005/com/nokia/WebArch1.1/resolvesAs
>>
>> Well, if we were starting from scratch, sure, but since we are
>> not, and can easily exploit the existing globally ubuiquitous
>> web, why start over?
>>
>>>
>>> Let me tell you a general basis for a concern I have with redefining
>>> the shared expectations of HTTP.
>>
>> Before you start, let me stress that a key point of this debate
>> is that I (and probably others) do not see this as "redefining
>> the shared expectations of HTTP" or in any way conflicting with
>> common user expectations about the web experience. So, again,
>> you're arguing on the basis of what I consider to be a false
>> premise...
>>
>>> An architecture allows growth by making constraints.
>>> http: (IMNSHO) is constrained to be a space of documents.
>>> mailto: is constrained to be a space of message destinations.
>>> These constraints give the architecture its form.
>>> They define http as a simple service which can be migrated to
>>> a different implementation (say a nifty peer-peer version)
>>> with time. Because the features delivered are constrained.
>>> Similarly with mailto: -- one could replace all of SMTP
>>> bit by bit while keeping the URIs because the service
>>> is just message delivery. No lookup.
>>>
>>> The unyielding medium is not only endured,
>>> it's that upon which Art depends:
>>> For who can perform on a tightrope secured
>>> at only one of its ends?" -- Piet Hein
>>>
>>
>> On principle, I agree 100% with what you state above about
>> constraints. Absolutely.
>>
>> This is not about constrants vs. no constraints. It is about
>> the nature and degree of those constraints.
>>
>> Alot of folks have found that a slight and intuitive (to them)
>> generalization (broadening) of certain (arguable) historical
>> constraints on the usage of http: URIs provids substantial
>> benefits without significant (or any) impact to current web
>> usability.
>>
>> It's that simple.
>>
>> We can take the "historical" view and say, that's not how
>> it was designed or intended to be used, and not advance. Or
>> we can take the "evolutionary" view and say, OK, some
>> "mutations" from the original are in fact beneficial, and
>> as the world changes, so too should things evolve.
>>
>> The advent of the semantic web is a major (some would say
>> cataclysmic ;-) change to the world wide web. The evolution
>> from t:identifies to p:identifies is (for the sake of arguement)
>> a mutation that is widely encountered on the web today, and it
>> has been found to be a very useful evolutionary step.
>>
>> I would hope that we wouldn't have to just wait and see which
>> variant species becomes extinct ;-) That could take *alot*
>> longer than most interested parties are, I think, prepared
>> to endure.
>>
>>>
>>>> Perhaps there's a gem of an idea buried under all this debate
>>>> which offers enough benefit to enough of the web community
>>>> to justify embracing this evolution of the original design.
>>>
>>> Certainly let's evolve it. But let's not break it.
>>
>> Wow. Hmmm... Since there is no hard evidence that this "mutation"
>> actually does break anything, perhaps this is a seed of potential
>> reconciliation on this issue -- such that, so long as there is no
>> clear evidence of breakage, such an evolution is acceptable?
>>
>>>
>>>> Just a thought...
>>>
>>> Thanks.
>>>
>>>> Warmest regards,
>>>>
>>>
>>> Likewise,
>>>
>>
>> Too bad we didn't have time or inclination to have this chat
>> in real-time in Boston... Oh well...
>>
>> Cheers,
>>
>> Patrick
>>
>>
>>> Tim
>>>
>>>> Patrick
>>>>
--
Patrick Stickler
Senior Architect
Forum Nokia Online
Tampere, Finland
patrick.stickler@nokia.com
>>>
>
Received on Monday, 14 March 2005 13:24:34 UTC