Re: [Moderator Action] another idea for the URN approach to local UIDs in bookmarks

Eric,

Thanks for giving a more concrete example. There's only a glitch
that I think made you miss the point of my proposal. 

The main point of using <b:base> (as you defined it) and
owl:sameAs is to keep track of the current and previous
location of statements. The problem we want to solve is
to be able to make a statement about another statement that is
inside a file that can be moved. Relative URLs are not good for
doing this.

The URN are a good solution to it, but I don't know how good
we will be in generating unique and distinct URNs in a non-controlled
environment (the whole world).

The solution I propose allows to have the same benefits as the
unique URN but it avoids collisions, The price to pay, however, is that
applications need to do much more processing.

What is easier to have, a fail-safe mechanism to produce URNs or
some well specified processing? If it's the former, then let's go
forward with URNs (and send a follow-up message on how to do it :).
Maybe you'd like to adopt the same mechanism used to generate msgids
by some mail client?

I'm basically proposing that the applications do the same job
that the server does when you publish something and it attributes
a new URL.

See below for additional comments.

On Wed, Mar 31, 2004 at 09:07:20AM -0500, Eric Prud'hommeaux wrote:

[snip]
> 
> > 5. When an RDF server sends back a set of bookmarks, it can include
> >    the Bookmark#Base property so that the application knows that they
> >    have the same base. This will make the way the file is stored
> >    (as a single file or inside a database) transparent to the
> >    application.
> 
[snip]
> 
> I haven't included the owl:sameAs assertion because it described the
> relationship between a universally identified resource
>   http://laptop.example.com/usr/local/bookmarks/current.rdf
> and a local resource that was created when there was no net access
>   file://localhost/home/jose/bookmarks.rdf

We don't need the owl:sameAs here unless this was a statement that
had a previous location.

> I think this is an interesting technique, and I'm glad to have worked
> through the details of it, but I think we still need the URN approach
> to deal with the scenario of documents that are shared before they get
> a universal name. For instances, a user could queue mail containing a
> local form (not yet named with a non-local name) while still on the
> plane [1].

With my proposal, you can share the documents too without needing
to have a universal name. The universal name is made of the location of
the file and the previous location is kept using owl:sameAs. This way
statements made about something that moved can still be tracked to the
new ones. It's just much more hazzle than URNs.

> Perhaps this approach addresses the mailed-local scenario in a way I
> haven't spotted.

Hope this makes it clearer.

-jose

Received on Wednesday, 31 March 2004 09:43:31 UTC