- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Wed, 31 Mar 2004 10:55:31 -0500
- To: public-annotea-dev@w3.org
On Wed, Mar 31, 2004 at 04:41:15PM +0200, Jose Kahan wrote:
>
> 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?
If we go with (temporary) UUIDs, yes, I think re-using something like
message ids would offer the maximum use of existing and testing tools.
I guess msgids are the most prolific of the globally "unique" UUIDs
currently being generated.
> 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.
ditto
> 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.
Following that through a bit: you share your bookmark with someone
else before nailing it down with a universal name. Supposed you
generate a bookmark, with xml:base and b:base of
file:///C:|/Windows/bookmarks.rdf . You mail the file to me (or at
least queue it) before you get a chance to post the bookmark to a
bookmark server. There may already be a file on my machine called
file:///C:|/Windows/bookmarks.rdf but my mail client is likely to warn
me before I overwrite it by saving the mailed bookmarks file in that
location. Prompted by the mail client, I save it to
<current directory>/bookmarks2.rdf
Now when I read that file from a bookmark-protocol-aware agent, it
changes the names of all the nodes in the graph that are fragments
based on file:///C:|/Windows/bookmarks.rdf .
This counts on the graph merging happening only with bookmark agents.
Any other tool would see the node called
file:///C:|/Windows/bookmarks.rdf#bm1
in a document called file:///C:|/Windows/bookmarks2.rdf and merge it
with the file:///C:|/Windows/bookmarks.rdf#bm1 from bookmarks.rdf .
Another requirement is that the server should not ever know about the
owl:sameAsr it will try to merge all of the things that it ever
learned had been called file:///C:|/Windows/bookmarks.rdf#bm1 at some
point in their history. For an example of this failure, suppose Jose
Kahan of Brittany creates
file:///C:|/Windows/bookmarks.rdf#bm1
and posts it to server1. server1 then says,
file:///C:|/Windows/bookmarks.rdf#bm1 owl:sameAs ...bm12321 .
Someplace out there on the net, someone else happens on the name bm1
and they post their notion of file:///C:|/Windows/bookmarks.rdf#bm1 .
The server is faced with trying to guess if this bm1 is the same one
that it heard about before. If it is, it should probably rename it to
the other name it already gave for bm1. Otherwise, it should give it a
new name, say ...bm13891, but not mention any owl:sameAs relationship
between the newly invneted name and
file:///C:|/Windows/bookmarks.rdf#bm1 .
For similar reasons, the client should never let *anybody* know that
bm1 owl:sameAs ...bm12321 as they will arrive at the same mistaken
conclusion that the bm1 and bm1 and ...bm12321 and ...bm13891 are all
the same node.
How coherent was that?
> > Perhaps this approach addresses the mailed-local scenario in a way I
> > haven't spotted.
>
> Hope this makes it clearer.
>
> -jose
--
-eric
office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
Shonan Fujisawa Campus, Keio University,
5322 Endo, Fujisawa, Kanagawa 252-8520
JAPAN
+1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell: +1.857.222.5741 (does not work in Asia)
(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
Received on Wednesday, 31 March 2004 10:56:47 UTC