Re: resources and URIs

>  > Is it the webcam itself, or the view from the window, or (suppose the
>>  webcam is in Peoria) Peoria?
>...
>>  It emits representations OF a view in Peoria, true; and the owner of the
>>  webcam might indeed declare that his site is about Peoria; but that is a
>>  semantic claim, not a network claim.
>
>To continue your webcam example: embellishing the representations with
>appropriate metadata about the representations *themselves* seems a lot
>more constructive than trying to assert properties about resources.

I agree that is important and useful and 
hopefully will be possible one way or another. 
However I think we need both data and metadata.

>
>For example, the HTML may include machine readable metadata stating the
>author, a brief description of the page, appropriate keywords, a link to
>the next page in some sequence defined by the author, and so on.
>
>The webcam images referred to from the HTML may include metadata stating
>the time they were taken, the equipment used to create them, a textual
>description of their content and so on. Alternatively, the image metadata
>may be located in the HTML in the form of attributes on the link.
>
>All of this metadata is describing representations, either those just
>retrieved or those that will be retrieved in the future. None of it is
>talking about resources, and URIs are only used at all to refer to the
>representations that will be returned by dereferencing them using HTTP.
>
>Doesn't this seem more useful than trying to decide whether the URI
>identifies/denotes a document, a webcam, or Peoria?

Don't get me wrong: I don't necessarily want us 
to decide things like that. BUt if the 
architecture description says what kind of thing 
is being identified, or says things about it that 
sound important, I want to get very clear about 
exactly what it is saying.

>
><hypothesis>
>
>The current design of the proposed semantic web relies on URI triples
>rather than hypertext markup, which I believe discards most of what made
>the web work.

Well, the SW isn't setting out to ban hypertext, 
or anything. Its just adding a new kind of 
representation to the mix, a kind that software 
inference bots can do something useful with, just 
as humans can do useful things with hypertext. It 
would be very nice if we could get the hypertext 
and the SW stuff more integrated, but first 
things first. Its hard enough to even get the SW 
stuff started by itself.

>
>If the design of the semantic web was adjusted to encourage the use and
>interpretation of textual markup with less reliance on overstressed and
>underspecified URIs the result would be a clearer and more powerful
>architecture that did not clash so awkwardly with the existing web.

Well, yes and no. We know we can't make inference 
engines that can reliably process text or 
hypertext, let alone things like cnn.com.  So the 
SW notations have to be made simple enough so 
that they can be usefully processed by the bots 
we know how to build.  Still, that said, I don't 
think the what-do-the-URI's-really-mean issue is 
nearly as important as  some folk think it is, 
for the SW. The SW in fact can get along pretty 
well for the time being without *any* 
architectural assumptions about URIs, or at any 
rate no more than are already needed for  things 
like http.  What does get in the way is when the 
architectural description insists on URIs having 
to be semantically conditioned in certain ways, 
in particular this idea that a URI must indicate 
a unique 'resource' creates all kinds of 
problems. The issue isn't "which resource is the 
right one", but rather "why does there have to be 
a right one??"

>
>Some principles along those lines would be:
>
>  * Only use fragment identifiers to refer to fragments of a representation
>retrieved using the URI. This is what they were created for, after all. 
>Using them to refer to non-existent parts of non-existent documents is not
>doing the web any favours.

Mostly the SW wants to use URIs with fragIDs (ie 
the aa:bb#cc thingies) to denote other things 
than documents altogether. Maybe this is 
consistent with what you are saying, I'm not sure 
what it means to say what a fragID refers to all 
by itself.

>
>  * Move more complicated linking schemes such as XPointer into the linking
>markup, to solve a host of issues by simplifying URIs, simplifying
>encoding/escaping and allow more interesting linking patterns to emerge.

Others have also suggested taking XPointer more 
seriously. This is outside my area of competence 
as yet.

>  * Stop trying to pin down arbitrary concepts using a unique URI. It is
>not necessary for there to be a canonical URI to identify "the Porsche
>911". It is sufficient to be able to say "the car in *this picture*" or
>the car "described in *this advertisement*". Question: does tel:555-1234
>identify a company, a department, a telephone handset, the person who
>answers it, the employee role of the person who answers it, the person who
>is *supposed* to answer it, or none of the above? Answer: it doesn't
>matter! Because any reasoning agent can say "the company whose number
>is..." or "the employee who answers when you call..." or any other
>necessary clarification. If telephone numbers do not identify a unique
>concept, neither do URIs.

I agree, though I can see the argument that 
having at least a kind of handy set of guidelines 
will be practically useful at least to get things 
started. But I can't see it being possible to 
maintain any sort of global unique-reference 
scheme, it just isn't feasible on a large scale.

>  * Take advantage of markup as a primary descriptive tool, not just a
>literal string hanging awkwardly off the end of an RDF predicate! But
>perhaps other people can carry this aspect of the discussion.

I think we have to defer that until we get more 
experience with real SW applications. I trust the 
world's hackers to invent workable compromises 
until we get our act together, though.

></hypothesis>
>
>Best regards,

Chaio

Pat

>Michael
>
>--
>YesLogic Prince prints XML!
>http://yeslogic.com


-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 24 July 2003 02:56:24 UTC