Re: ISSUE-58: Scalability of URI Access to Resources

Norm Walsh said:
> No, my point wasn't that there will inevitably be a need to dereference them. The point I was trying to make was that *if* you need to dereference them, you need to dereference them and the scheme of the URI isn't really the important part.

Ofcourse.  You can address, the scalability bottleneck for URI access
either at the server (which would be _mostly_ orthogonal to web
architecture), within the transport layer (with ample use - of and
guidance for - caching directives),  or at the client (with pragmatic
guidance about 'arbitrary' dereference).

The second point started off with "Suppose that you avoid http:
because you're worried about the cost  of dereference." This scenario
is obviously motivated by a goal of addressing the bottleneck at the
client, so suggesting that *if* you need to dereference you have a
problem regardless seemed a bit... circular.

Norm Walsh said:
> A different usage pattern from web browsing by a human being, perhaps, but do you really think it's different from what other software agents do, for example, XML validation in an application server?

Absolutely! XML validation deals mostly with grammatic well-formedness
checking of nodes (some of which may have a URL component for their
names). Assuming the schema has been associated apriori, there really
isn't much of 'need' to dereference the names.  The names are
attributes (not to be confused with @foo) of items in an infoset,
there is no 'formal' denotation.

RDF is rather different (due to it's model theory) in that the use of
URIs is explicitly meant to formally _denote_ 'things' (a subset of
which are be information resources).  GRDDL defines a more constrained
usage pattern insofar as the mechanism is primarily concerned with the
_information resources_ denoted (recursively) within RDF graphs and
used as arguments to specific predicates.

This is perhaps off topic, but I do think for this very reason (the
difference in the way things are denoted) it is problematic to
judiciously apply Web architecture principles of URIs to RDF (even
though, as Pat points out, the RDF specifications don't make any
distinction).  Some of the consequences of this bottom-out into
ISSUE-58: unnecessary dereferencing of representations which do not
contribute to the model of the world an RDF agent is working with and
the constraints that apply.

Norm Walsh said:
> I don't agree. There's no transport protocol associated with urn: scheme URIs, but if you need to dereference them, then you need to dereference them. Granted, you'll have to use a different architecture, but at the end of the day, you'll still be banging on some server somewhere for the representation and this issue will arise..

Consider the tag scheme then.  It has no transport protocol, so
regardless of whether there is a need to dereference URIs which use
this scheme (it would seem odd to explicitly use tag URIs and then
have a need to dereference them at a later point) there is no
dereference problem.  There is no problem *precisely* because it
doesn't have a transport mechanism.

Received on Friday, 24 August 2007 13:21:58 UTC