another idea for the URN approach to local UIDs in bookmarks

Last Friday I missed the last bus home. While walking 9 km back home,
I thought about this problem and came up with another less polemical
solution, but that requires more application involvement. 

It's basically applying what the server already does when attributing 
URLs and keeping state using owl:sameAs.

1. Define a new property, Bookmark#Base which is the equivalent of
   xml:base and html:base. The value of this property will be the
   location of the local bookmark file. It's a way of keeping this
   information without having parsers losing it (by applying it to the
   URLs.

2. Give anything as a name to bookmarks and topics, but make sure the
   base of their URL is the same as the one defined in Bookmark#Base.

3. When opening a file, check the value of Bookmark#Base. If the
   file contains bookmarks or topics that have a different base,
   assume that the file has changed location.

   In this case, have the application reassign new URLs for all its
   topics and bookmarks using the current base and, for each item,
   store the previous URL value using owl:sameAs. We can have
   the application prompt the user "do you want to keep track
   of the previous location?" in case the user is just moving the
   bookmark file around, but has not made any RDF statements about any 
   of the items it contains.

4. Use owl:sameAs to track statements made about the previous URLs
   and have the application resolve them.

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.

6. If I have a single bookmark file and I put it to the server using
   a specific "Save As" for bookmarks, the application can rewrite the
   URLs and add the owl:sameAs when writing the file. 

   If this is not done, the application will catch the error when
   reading a file that has a different base.

Does this make sense to you compared to the previous URN approach?
It puts a bigger burden on the application, but makes things work
even if a file moves around... and it removes the burden from us
of guaranteeing we have a unique URN for each item.

-jose

Received on Wednesday, 31 March 2004 08:18:48 UTC