RE: httpRange-14 , what's the problem

Start with:
http://lists.w3.org/Archives/Public/www-rdf-interest/2002Apr/0124.html

But just to clarify what we are NOT arguing about:

1.  Everyone (even RDF) agrees that "http: URIs" should be used to
identify resources which are generally lumped together and called
alternately: hypermedia, hypertext, documents, web pages, and so on.

2.  Everyone also agrees that "http: URIs" should be strongly preferred
for identifying resources, IF those resources are most naturally dealt
with through transfers of representational state.  (In other words, if
you envision interacting with the resource primarily through a web
browser UI and synchronous request+response pairs, use the http: scheme)

Those use cases for http: identifiers are well-established.  The
proponents of expanding the range of http are making three generalized
arguments: 

A. Some people claim that *all* resources which one would care to
identify can (and should) be dealt with through REST, and therefore rule
#2 applies.  And even if you think that a web browser UI and
request+response interaction makes absolutely no sense to your class of
resources, these people want you to use http: identifiers *anyway* --
Web browsers are only good at doing http: so you might as well name all
things in the world http: "just in case" it turns out that they could be
useful in http -- that way there is a slight chance it could one day
work in a web browser.

B. Some people claim that the idea of "hypermedia" can (and should) be
ambiguous enough to encompass all named things, and therefore rule #1
applies.  Just give it a new mime-type (object/car).

C. Some people claim that identity is inherently ambiguous, and
therefore URIs are meaningless to begin with.  Since a URI doesn't
*really* identify anything, it doesn't matter what scheme you use.  This
is the perversion of "minimally constraining".

A, B, and C are what people are arguing about.


(minor comments inline below)
----------------------------------------------------------------------


> problem is.  In RDF, I can assert that the resource
> http://example.com/23ru30u2 has a property named "Title" whose value
is
> "Lorem ipsum".  It may be the case that an HTML representation of that

You are describing scenario #1, so there is no disagreement.  It is fine
to make RDF assertions about things that are identified using http:
identifiers. RDF does not discriminate based on scheme.  You will get
challenged if you decide to use an http: identifier to identify
something that is clearly NOT in scenario #1 or #2 above.  However, from
the little we can glean from the example, using an http: identifier
seems appropriate according to those two generally accepted conventions.

> My own view of what a resource is may be found in
> http://www.textuality.com/tag/s1.1.html

That seems OK to me.

> out: given a URI, while you can potentially retrieve a representation
of
> the resource, you can't find out what the resource is.  There is no

From the POV of the semantic web, it's the opposite.  You can
potentially find out what the resource is, but there is a good chance
that you will NOT be able to dereference it.

In other words, synchronously retrieving a representational state of a
resource is not the only thing that you can do with a resource
identifier.  In fact, I expect that the vast majority of entities which
are identified on the semantic web will NOT support synchronous
retrieval of representational state.  Of course, the subset of entities
which *are* aptly identified with http: identifiers will be equal
citizens in the land of RDF, but it is falling into trap "A" above to
think that *all* entities should be identified with http: identifiers.


> http://weather.yahoo.com/forecast/MXOA0069.html and realize that the
> resource is really "Yahoo's weather forecast for Oaxaca".  In fact,
this
> is why we need RDF or equivalent - to provide a standardized way to
make

Again, this is scenario #1.  People normally think of a "weather report"
as being something that they read, and it fits the "hypertext" category
very nicely.  RDF can certainly make assertions about these resources.
However, RDF is not constrained to only making assertions about things
that easily fit into the HTTP mould.

Received on Wednesday, 17 July 2002 03:36:34 UTC