RE: [OT] RE: Using URIs to identify non-information resources

On 19.08.2005 20:50:35, Booth, David (HP Software - Boston) wrote:
>>    yes. (as long as there is no "?" in the page's URL)
>
>Actually, my reading of RFC3986 ( http://www.faqs.org/rfcs/rfc3986.html
>) is that "?" *is* permitted in the query string:
>
>  absolute-URI  = scheme ":" hier-part [ "?" query ]
>  . . .
>  query         = *( pchar / "/" / "?" )
But your service doesn't redirect to those URLs correctly.

re the other arguments: You are trying to eat your cake and have it,
too: When I say, your redirect solution doesn't scale, you agree but
say the service does because of URI examination. When I say, you
shouldn't rely on URI examination, you agree as well but say the
system uses redirects in this case. You also say that a multitude of
services would be fine (for scalability reasons), but that a single
service would be better (for scalability reasons).

A final note: I'm just one implementor, but, to be honest, I don't
expect folks will give away URI authority to a centralized service
(for the technical reasons mentioned, and probably even more for
the implications Dan listed) when the same functionality can be
implemented in e.g. 10 lines of php code on any cheap, hosted web
server.

regards,
benjamin

--
Benjamin Nowack

Kruppstr. 100
45145 Essen, Germany
http://www.bnode.org/


On 19.08.2005 20:50:35, Booth, David (HP Software - Boston) wrote:
>Benjamin,
>
>Thanks for your comments!  More explanations below.
>
>> . . .
>> (note that I don't want to dis your service, I just don't 
>> think swbpd is the right place to promote it beyond the 
>> general technique behind) . . . .
>
>I agree.  The general technique is exactly what I am trying to promote
>-- not the thing-described-by.org domain in particular.  I apologize for
>not making that clearer.  I am using thing-described-by.org as a
>concrete example of the kind of 303-forwarding service that I am
>advocating.  I don't think the SWBPD WG should endorse any particular
>domain (except perhaps as one example among others); I *do* think the
>SWBPD WG should endorse the general technique if it becomes established
>practice.
>
>> . . .
>> - an ontology isn't a service, your "analogy" doesn't work.
>> - the option to not use a certain service doesn't change the 
>> service's nature. . . . 
>
>If the ontology is based on http URIs, then that ontology's domain
>certainly *is* a service if its URIs serve up useful information when
>they are accessed, which clearly is recommended practice.  For example,
>suppose the ontology is based on the domain colors.example.org.  Then
>there are two uses for the URI http://colors.example.org/blue :  as an
>unambiguous identifier for a particular color; and as a source of
>information about what that URI means.  The first use is not as a
>service; the second clearly is.
>
>This is exactly analogous to thing-described-by.org URIs.  You could
>argue that the usefulness of the colors.example.org ontology does not
>depend on its dual function as a service, but the exact same thing is
>true of thing-described-by.org URIs.
>
>In fact, one accurate way to think of thing-described-by.org is that its
>URIs represent an ontology!  However, authority for defining the meaning
>of each term in the thing-described-by.org ontology is decentralized: it
>is delegated to the owner of the sub-URI that is given in the query
>string, as described at
>http://thing-described-by.org/#Delegation_of_Authority
>
>So thing-described-by.org is a "service" to the same extent that
>colors.example.org is a "service", and it is a "centralized service"
>only to the extent that colors.example.org is a "centralized service":
>by the network effect of those who choose to adopt it -- not be decree.
>
>> >It is very different from defining a new URI scheme, because it does 
>> >not require any changes to existing software.  It works today.  
>> >However, if you do wish to change your software to recognize 
>> >thing-described-by.org URIs, then your software can run faster, by 
>> >opimizing away unnecessary HTTP accesses, as described at 
>> >http://thing-described-by.org/#optimizing
>> 
>> AND http://t-d-b.org/ AND http://my-t-d-b.org/ AND http:...
>
>Correct.  But even if your software had to recognize 100 of these
>domains -- or even 1000 or 10000! -- it would still be orders of
>magnitude faster than performing an extra HTTP network access.  And of
>course there's no need for these domain names to be hard coded, as a
>list could simply be loaded (or downloaded) during initialization.
>
>> . . . 
>> > However, if you are given a thing-described-by.org URI, you can 
>> > determine by inspection that it does not directly identify a 
>> > document at that address, because of the delegation of authority 
>> > provided by thing-described-by.org: 
>> > http://thing-described-by.org/#Delegation_of_Authority
>> > That is a significant optimization.
>> 
>> That seems to be the part that's related to SWBP:
>> Should this WG propose a mechanism that relies on URI 
>> examination? (Guess my personal opinion ;)
>
>I assume you're referring to the Web tenet of URI opacity, which is
>important.  But the thing-described-by.org approach does *not* "break
>URI opacity":
>
>1. There is no *need* to examine the structure of the URI.  It will work
>exactly right (returning a 303 redirect to another page) even if you do
>not look into the URI's structure.  
>
>2. The reason and intent behind the principle of URI opacity is to
>prevent someone who inspects a given URI from drawing false conclusions
>about its meaning.   But if you *choose* to look at the structure of a
>thing-described-by.org URI, and you were already aware of the delegation
>of authority provided by the thing-described-by.org site (see 
>http://thing-described-by.org/#Delegation_of_Authority ), then you could
>*correctly* optimize away the HTTP access to thing-described-by.org.
>Note that this is *not* a heuristic (guess)!  It is following the
>explicitly defined meaning of the URI, as documented at 
>http://thing-described-by.org/#Delegation_of_Authority .  
>
>> >> (It would be nice though to see a swbpd note about how to best 
>> >> implement the TAG suggestion, possible ways of naming resources so 
>> >> that the 303-mechanism works, . . . .
>> >
>> > The question of how to best implement the TAG's suggestion, 
>> > and how to best name resources so that the 303-mechanism works, 
>> > is *exactly* what  am trying to address in suggesting the 
>> > thing-described-by.org approach!
>>
>> yeah, but you are proposing it as a service, not as a 
>> technique/practice. 
>
>No, my intent is to propose the technique/practice, as explained above.
>I'm merely using thing-described-by.org as a working/usable example.  I
>definitely erred in not making that clearer earlier. (Sorry!)  :(
>
>> and I actually think it'd be more 
>> straight-forward to simply tell people how to adjust their 
>> htaccess files to make the 303 mechanism work directly on 
>> their systems. but maybe that's just me.
>
>I think that approach (custom 303-forwarding) has its place also --
>mainly because it gives shorter URIs and does not depend on someone
>else's domain -- but it has some clear disadvantages in comparison to
>the thing-described-by.org approach:
>
>1. It's a lot easier (IMO) to teach someone how to mint a
>thing-described-by.org URI than to teach them how to configure their Web
>server for a 303-redirect -- assuming they even have the ability to do
>so.  In many cases, Web authors do not have that much control over their
>server configurations.
>
>2. If everyone does their own custom 303-forwarding then you lose the
>ability to optimize away the extra HTTP access, which means that systems
>cannot scale as well.
>
>> > AFAICT, thing-described-by.org provides a very practical and 
>> > scalable solution to the problem.
>>
>> for "page exists, URI needed" situations:
>>    yes. (as long as there is no "?" in the page's URL)
>
>Actually, my reading of RFC3986 ( http://www.faqs.org/rfcs/rfc3986.html
>) is that "?" *is* permitted in the query string:
>
>  absolute-URI  = scheme ":" hier-part [ "?" query ]
>  . . .
>  query         = *( pchar / "/" / "?" )
>
>
>> for automatically generated URIs of individuals:
>>    an ideal consequence of your proposal (if taken seriously) is that
>>    every non-info resource should be prefixed with 
>> "http://t-d-b.org/?". 
>>    So, systems creating your URIs would then ideally auto-generate
>>    pages for requests coming back from your service's 303s. But when
>>    I have to adjust my apps to prefix internal URIs and to 
>> later detect
>>    incoming requests for theses resources (which means that I have to
>>    store two URIs, or I have to prefix URIs retrieved from an 
>> RDF store,
>>    or I have to adjust SPARQL queries), I can more easily 
>> implement the
>>    whole mechanism directly without running into issues.
>> 
>> for already existing URIs of non-info resources:
>>    no. there is no efficient way to "upgrade" existing URIs to your
>>    service without changing them.
>
>I agree, there is inherent inefficiency in changing existing URIs.  I
>should never have implied otherwise.   :(  
>
>But if existing URIs are going to be changed at all to conform to the
>TAG's guidance, then the thing-described-by.org approach is the most
>general, efficient and non-disruptive alternative that I have seen so
>far:
>
>	General: Because the meaning of the URI is independent of 
>	media type (unlike with # URIs;
>
>	Efficient: Because unnecessary HTTP accesses can be optimized 
>	away; and
>
>	Non-disruptive: Because it does not require any change to 
>	existing software.  It works today.
>
>David Booth
>
>

Received on Saturday, 20 August 2005 12:08:59 UTC