Re: Resources and URIs

> For anonymous resources, I don't think your proposal can work in the way
> you hope.

I am deeply convinced that we need the ability to refer to anonymous
resources. Refer to

	http://www.bootstrap.org/augment-132082.htm#11K

for supporting arguments.

> URIs are just more information about a resource, as are
> temporary placeholder URIs.

Remember my disclaimer about the semantics: it is out of scope.

>          "it is essential that every parser is guaranteed to produce the same URI
>         for the resource. Period."
> 
> This is a very strong statement, and one that could be qualified in a
> number of ways.

Right. The strength of the statement depends on this qualification. 

> Do you mean: produce the same generated URI for the same (anonymous) resource
> 
>         - given byte-for-byte identical XML input (from same source)
>         - given byte-for-byte identical XML input (from different sources)
>         - given statement-for-statement identical graphs from varying sources

In my view, the above statement must be true *at least* for the first
case: given byte-for-byte identical XML input from same source, the same
noname URI should be produced. This is the weakest possible assumption,
and it is easily satisfiable. I don't think the uniqueness assumption
makes sense for different sources. Your Example 1 illustrates that very
well.

> ...
> Example 1: same XML bytes, different servers
> ...

However, I do believe that a unique noname URI makes sense in your
second example:

> Example 2: same XML bytes, same server, different resource.
> 
>         <rdf:RDF>
>         <WeatherReport>
>         <todayCloudCoverPhoto rdf:resource="/weathertoday.png"/>
>         <description>this is a daily weather report; the
>         todaysCloudCoverPhoto property is a reference to a dynamically changing
>         resource, created by a different person each day</description>
>         </WeatherReport>
>         </rdf:Description>
>         </rdf:RDF>
> 
> Feeding this to an XML/RDF parser we'd get an anonymous resource of type
> "WeatherReport". On different days we might get descriptions of different
> (anonymous) WeatherReports.

In the above example, you would get the same URI for the instance of
"WeatherReport" whenever you stopped by at the server. And, if you
insist on considering the semantics of this resource, it would identify
the "current" whether report from the given datasource, whatever
"current" means. When presented to the user at runtime by a weather
report application, the report would indeed reflect the current whether
situation.

> stuck. Writing out parsers so they try to always generate the same
> identifier given sufficent context (server, date, content-negotiation,
> language-negotiation, bytes-to-parse etc) seems to me fraught with
> difficulty.

I agree there are unresolved issues here. However, I tend to believe
Doug Engelbart (see URL above) that this is a crucial requirement. By
restricting the context say to the origin and content of the RDF
description the problem can be solved relatively easily.

> My inclination is to run the other way and make sure that these URIs are
> evident as generated IDs, so that processors can always tell when the URI
> was cooked up by some parser instead of being widely agreed.

This is in fact not the *other* way, but just the half of the way. Using
Gabe's proposal we could generate a URI like

urn:rdf:noname:XYZ        (where XYZ is again based on a digest)

Thus, it is evident that it is a generated ID. But we go further. Have a
look at the above quoted URL:

	http://www.bootstrap.org/augment-132082.htm#11K

If Doug had not provided the anchor #11K, I couldn't have referred to
this essential requirement. This is a serious limitation of HTML. I
could have done it in case of XML, namely, using XPointers (given that
the content remains unchanged). The same with RDF: if I have an RDF
document that lists requirements for an open hyperdocument system, I
need to be able to point to the paragraph describing the requirement
"11K". If I used Gabe's content-based algorithm for that, I could even
make sure that if the author changes the text of the requirement, the
link is broken, which is good, since I quoted the original sentence, and
not the modified one.

Sergey

Received on Tuesday, 7 December 1999 20:01:14 UTC