Re: URIs: Identifiers in name, but...

> The binding of search URLs to resources is done on the fly
> by the search engine. This binding does not have, nor would
> it be good for it to have, persistence.

I guess the moral here then is that what URIs "identify" should not be
limited to any form of abstraction, as the URI RFC (partly) implies.
Still, people have certain expectations about URIs - you know that if
you dereference the result of a search engine, then it's not going to
change drastically to the next second, or at least the chances of that
are fairly slim. What one can do is create an entirely new resource
which represents the search result from a given search engine on a
given date:-

     :x :URI <http://search.org/?=mysearch>;
        dc:date "2001-03-17 20:05:78.0925" .

and then you can make claims about :x if need be, but because of
contextualization, we know that this is rarely required. If I point
you to a search result, I expect the URI to identify some concept of a
search result. I would hope that it always identifies this long enough
for me to get the information over to you, but if it doesn't I can
follow the method above. [N.B. We found that this was the case with
EARL [1] when making evaluations about some kind of resource, you have
to qualify the time aspect of it, and possibly even the whole bundle
of semantic assertinos themselves].

So as ever, contextualization and agreement are the biggest facotrs in
any URI scheme - even when (especially when) the URI in question is
defining some sort of "procedure" rather than a concept. In other
words, paraphrasing Sandro's comments (I forget where), I don't see
any problem with a URI identifying a mechanism for obtaining a network
entity *and* some concept of what the network entity defines, as long
as you are very tight indeed with the contextualization. On a broader
scale, this is probably inadvisable.

[1] http://www.w3.org/2001/03/earl/

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Wednesday, 2 May 2001 13:48:40 UTC