W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2000

Re: Digest URI's

From: Sergey Melnik <melnik@db.stanford.edu>
Date: Sun, 09 Apr 2000 21:26:33 -0700
Message-ID: <38F157F9.F1C79B27@db.stanford.edu>
To: "McBride, Brian" <bwm@hplb.hpl.hp.com>
CC: "'www-rdf-interest@w3.org'" <www-rdf-interest@w3.org>
"McBride, Brian" wrote:
> ...
> My reading of the spec is that anonymous resources appear in the model, not
> just in the syntax [m&s fig2, fig7]. Yes?  No?  This is the heart of my
> problem.

Currently there is no standard way to mark resources in a model as
anonymous. For me, anonymous resources are a purely syntactic artifact
as long as they are not manifested in the model (same for language
tagging).

> 2) What are they for?
>         Model URI's give us a digest to sign a model's content.
> 
>         [A digest algorithm would be sufficient for this - doesn't have to
> be a URI - Yes/NO?  What advantage does making it a URI bring?]

You can make RDF statements about a model.

>         Unnamed resources can be referred to.
> 
>         [I don't get that either.  The algorithm for referring to unnamed
> resources depends on a particular seriliazation.  If I've plonked an
> anonymous resource directly into a model in a database how do I compute its
> digest?

If someone puts an RDF page on the Web in a given serialization that
uses anonymous resources, then, given a standard algorithm for assigning
URIs (e.g. digest-based) for anonymous resources, it is possible to
refer to them in a consistent way across different apps.

>         Does this have knock on effect?  The digests for statements
> referring to the unknown resource depends on the digest for that resource,
> and the digest for the model depends on the digests for those statements.

This is a weak point indeed. If a GUI app is used to create the model,
well, it already has some URIs for all resources. If is it written used
some serialization syntax, and you want to sign the model (the content),
you could pipe it through the parser and serialize it back (assuming
that the serialization uses explicit URIs for everything) if you want to
avoid having a "dirty" model URI. Still, a model URI based on a digest
only makes sense if you can get the content somewhere. If everybody uses
the same alg to generate URIs, they will get the same model even if it
uses anonymous resources. But I agree, this is somewhat ugly.

>         So maybe the idea is:  If a resource is added into a model by a
> program, then it is required to give it a URI - a guid or whatever.  But
> since people are not very good at generating guid's, when a human writes
> some RDF serialization which includes an anonymous resource, then the parser
> has a standard algorithm for calculating a URI for that resource.  If that
> is the case, then is this really a suggestion to remove anonymous resources
> from the RDF model?]

This is exactly my understanding of the role of anonymous resources. As
mentioned, I believe anonymous resources don't belong to the model.

> Would the proposed algorithm assign the same digest URI to both the authors
> (they are a husband and wife team) in the following fragment of serialised
> RDF?
> 
> <?xml version="1.0"?>
> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>          xmlns:DC="http://purl.org/dc/elements/1.0/">
> 
> <rdf:Description about="http://homepage/SmithFamily">
>   <author>
>      <rdf:Description>
>         <surname>Smith</surname>
>      </rdf:Description>
>   </author>
>   <author>
>      <rdf:Description>
>         <surname>Smith</surname>
>      </rdf:Description>
>   </author>
> </rdf:Description>
> </rdf:RDF>

Yes. There is no way to distinguish between these two resources based on
the context (remember, the digest algorithm should to be
order-independent, therefore XML ordering does not count).

However, even a human (at least me ;) would have difficulties
disambiguating the above RDF description: did the author really mean two
different entities, or was it just a cut-and-paste typo?

Best,
Sergey
Received on Monday, 10 April 2000 00:29:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:43 GMT