This is an early draft of a protocol under consideration. It has not been implemented (or tested). Further, this document is a work of the authors (listed below) and does not constitute any endorsement by the membership of W3C.
The desire to identify resources globally is in tension with a desire to create them autonomously create even when a user is offline or does not have access to create global URL identifiers. This is also true with Annotea, where a user should be able to create resources, such as annotations, topics and bookmarks, and name them with an ID that works both locally on his or her machine or globally when the resources are published to the Web.
When global HTTP identifiers are available the user can refer to the Annotea resources reliably and consistently. However, it is difficult when only local IDs are available or they are changed to HTTP identifiers only later when they become available. Currently we have experimented with two cases:
The first case, the annotation server case, works well. It leverages the ability of the annotation server to create globally unique URLs to idenify annotations. However, there are desires to extend the approach e.g. to be able to publish the annotation metadata also as a Web resource that can be attached to the snapshot of the annotated file.
In the second case, the bookmark case, we have a problem where local
file: URIs that we have been temporarily using as IDs are not
necessarily unambiguos when published to the Web. For instance, people may
unknowingly reuse the URI file://laptop/topics/Chat to mean
different things (informal discussion, IRC or IM meeting room name, or French
for "cat". We need a solution that avoids this ambiguity.
This document discusses some user scenarios and possible alternatives for generating local and global IDs and their advantages and disadvantages and a describes the solution that we have chosen for the bookmark case.
Here is a summary of some user requirements related to the bookmark and topic IDs.
Also we would like to do as little rewriting of the IDs in the local files as possible.
Thomas creates couple of bookmarks for fruit information documents and stores them in a local file named "file://localhost/bookmarks.rdf". Part of the information in the bookmark file is presented in Figure 1 (see complete Annotea bookmark schema). It includes a bookmark automatically named "bm1" recalling the document "http://sample.example.com/appledoc" and another bookmark named "bm2" recalling "http://demo.example.com/orangedoc". It also has a topic named "topic1".
<r:RDF>
<r:Description r:id="topic1">
<dc:title>fruitinfo</dc:title>
<b:subTopicOf r:resource="#MyHomeTopic"/>
</r:Description>
<r:Description r:id="bm1">
<b:recalls r:resource="http://sample.example.com/appledoc"/>
<b:hasTopic r:resource="#topic1"/>
</r:Description>
<r:Description r:id="bm2">
<recalls r:resource="http://demo.example.com/orangedoc"/>
<b:hasTopic r:resource="#topic1"/>
</r:Description>
</r:RDF>
Figure 1: Part of Thomas' bookmark file with one topic and 2 bookmarks.
The bookmark and topic names are relative to the base URL of the bookmark file. When interpreting the metadata shown in Figure 1 it results in the statements with absolute URIs shown in Figure 2.
<file://localhost/bookmarks.rdf#topic1> title "fruitinfo" . <file://localhost/bookmarks.rdf#topic1> subTopicOf <file://localhost/bookmarks.rdf#MyHomeTopic> . <file://localhost/bookmarks.rdf#bm1> recalls <http://sample.example.com/appledoc> . <file://localhost/bookmarks.rdf#bm1> hasTopic <file://localhost/bookmarks.rdf#topic1> . <file://localhost/bookmarks.rdf#bm2> recalls <http://demo.example.com/orangedoc> . <file://localhost/bookmarks.rdf#bm2> hasTopic <file://localhost/bookmarks.rdf#topic1> .
Figure 2: Statements from Thomas' bookmark file by using absolute URI's.
Thomas meets Sandy at the open market and tells her about his cool bookmark file. Sandy wants to see the bookmark file so Thomas promises to send it to her by mail as she has no access to Web publishing. But Sandy is so excited after talking with Thomas that she starts his own bookmark file on fruits while waiting the mail from Thomas. Sandy's bookmark metadata is presented in Figure 3 and it results in the statements shown in Figure 4.
<r:RDF>
<r:Description r:id="bm1">
<b:recalls r:resource="http://foo.org/peardoc"/>
<b:hasTopic r:resource="#MyHomeTopic"/>
</r:Description>
<r:Description r:id="bm2">
<recalls r:resource="http://sample.example.com/appledoc"/>
<b:hasTopic r:resource="#MyHomeTopic"/>
</r:Description>
<r:Description r:id="bm3">
<recalls r:resource="http://bar.org/peachdoc"/>
<b:hasTopic r:resource="#MyHomeTopic"/>
</r:Description>
</r:RDF>
Figure 3: Part of Sandy's bookmark file.
<file://localhost/bookmarks.rdf#bm1> recalls <http://foo.org/peardoc> . <file://localhost/bookmarks.rdf#bm2> recalls <http://sample.example.com/appledoc> . <file://localhost/bookmarks.rdf#bm3> recalls <http://bar.org/peachdoc> .
Figure 4: Statements from Sandy's bookmark file by using absolute URI's.
Soon afterwards Sandy receives the bookmark file from Thomas. The e-mail program stores it to "file://localhost/mail/bookmarks.rdf" so that now the metadata from Figure 1 with relative IDs results in the statements in Figure 5.
<file://localhost/mail/bookmarks.rdf#topic1> title "fruitinfo" . <file://localhost/mail/bookmarks.rdf#topic1> subTopicOf <file://localhost/mail/bookmarks.rdf#MyHomeTopic> . <file://localhost/mail/bookmarks.rdf#bm1> recalls <http://sample.example.com/appledoc> . <file://localhost/mail/bookmarks.rdf#bm1> hasTopic <file://localhost/mail/bookmarks.rdf#topic1> . <file://localhost/mail/bookmarks.rdf#bm2> recalls <http://demo.example.com/orangedoc> . <file://localhost/mail/bookmarks.rdf#bm2> hasTopic <file://localhost/mail/bookmarks.rdf#topic1> .
Figure 5: Statements from the bookmark file Sandy received by mail from Thomas.
Sandy opens the bookmark file attachment and copies the bookmarks and topics from it to her own file and then adds her own bookmarks under the same topic. In this case there are no problems because copying bookmarks and topics with his Annotea tool assigns them new IDs as shown below e.g. "thomastopic1".
<r:RDF>
<r:Description r:id="thomastopic1">
<dc:title>fruitinfo</dc:title>
<b:subTopicOf r:resource="#MyHomeTopic"/> .
</r:Description>
<r:Description r:id="thomasbm1">
<b:recalls r:resource="http://sample.example.com/appledoc"/>
<b:hasTopic r:resource="#thomastopic1"/>
</r:Description>
<r:Description r:id="thomasbm2">
<recalls r:resource="http://demo.example.com/orangedoc"/>
<b:hasTopic r:resource="#thomastopic1"/>
</r:Description>
<r:Description r:id="bm1">
<b:recalls r:resource="http://foo.org/peardoc"/>
<b:hasTopic r:resource="#MyHomeTopic"/>
</r:Description>
<r:Description r:id="bm2">
<recalls r:resource="http://sample.example.com/appledoc"/>
<b:hasTopic r:resource="#MyHomeTopic"/>
</r:Description>
<r:Description r:id="bm3">
<recalls r:resource="http://bar.org/peachdoc"/>
<b:hasTopic r:resource="#MyHomeTopic"/>
</r:Description>
</r:RDF>
Figure 6: Metadata when Sandy uses Annotea application to copy bookmarks and topics to his own bookmark file.
Problems arise when Sandy (or his tool) decides to not copy the topic from Thomas and give it a new ID "thomastopic1" but instead use the original topic named "topic1". Because that topic is now relative to "file://localhost/mail/bookmarks.rdf" we need to use "../mail/bookmarks.rdf#topic1" as its name instead of the plain "topic1". But now there is no connection between Sandy's topic and Thomas' original topic.
If the topic ID were absolute in Thomas' bookmark file e.g. "file://localhost/bookmarks.rdf#topic1" it would also be problematic because it would now be interpreted as relative to Sandy's computer.
If we use absolute local URIs in the bookmark files and then merge them we run into serious node conflation problems. For instance, Sandy and Thomas both have a bookmark file with URI "file://localhost/bookmarks.rdf". Let's assume that all the IDs in their bookmark files are absolute file URIs e.g. "file://localhost/bookmarks.rdf#bm1". It does not matter whether the absolute IDs are written down everyplace they occur or whether they are constructed by using an xml:base URI at the beginning of the file.
When the two bookmark files are merged they need to be published so that the application can retrieve them or collect by e-mail etc. in which case all the relative URIs in each file always get a different base URI. However, when we have used absolute addresses they may not be changed by the application and we have conflicts. In the following is an example of this. The description of bookmark "file://localhost/bookmarks.rdf#bm2" conflicts and it seems to be related to both appledoc and orangedoc. See the metadata in Figure 7.
<r:RDF>
<r:Description r:about="file://localhost/bookmarks.rdf#topic1">
<dc:title>fruitinfo</dc:title>
<b:subTopicOf r:resource="file://localhost/bookmarks.rdf#MyHomeTopic"/> .
</r:Description>
<r:Description r:about="file://localhost/bookmarks.rdf#bm1">
<b:recalls r:resource="http://sample.example.com/appledoc"/>
<b:hasTopic r:resource="file://localhost/bookmarks.rdf#topic1"/>
</r:Description>
<r:Description r:about="file://localhost/bookmarks.rdf#bm2">
<recalls r:resource="http://demo.example.com/orangedoc"/>
<b:hasTopic r:resource="file://localhost/bookmarks.rdf#topic1"/>
</r:Description>
<r:Description r:about="file://localhost/bookmarks.rdf#bm1">
<b:recalls r:resource="http://foo.org/peardoc"/>
<b:hasTopic r:resource="file://localhost/bookmarks.rdf#MyHomeTopic"/>
</r:Description>
<r:Description r:about="file://localhost/bookmarks.rdf#bm2">
<recalls r:resource="http://sample.example.com/appledoc"/>
<b:hasTopic r:resource="file://localhost/bookmarks.rdf#MyHomeTopic"/>
</r:Description>
<r:Description r:about="file://localhost/bookmarks.rdf#bm3">
<recalls r:resource="http://bar.org/peachdoc"/>
<b:hasTopic r:resource="file://localhost/bookmarks.rdf#MyHomeTopic"/>
</r:Description>
</r:RDF>
Figure 7: Merging Sandy's and Thomas' metadata in case they used absolute local URIs.
Sandy meets Thomas again with some other people who now want the copy of the combination bookmark file. Sandy has a sister who knows about the Web so instead of sending the file again by mail she helps Sandy to get a domain on the Web and to publish the bookmark file to address "http://sandy.com/bookmarks.rdf". Now Sandy is making the following statements in addition to the earlier statements he is still making in his local copy of the bookmark file:
<http://sandy.com/bookmarks.rdf#thomastopic1> title "fruitinfo" . <http://sandy.com/bookmarks.rdf#thomastopic1> subTopicOf <http://sandy.com/bookmarks.rdf#MyHomeTopic> . <http://sandy.com/bookmarks.rdf#thomasbm1> recalls <http://sample.example.com/appledoc> . <http://sandy.com/bookmarks.rdf#thomasbm1> hasTopic <http://sandy.com/bookmarks.rdf#thomastopic1> . <http://sandy.com/bookmarks.rdf#thomasbm2> recalls <http://demo.example.com/orangedoc> . <file://sandy.com/bookmarks.rdf#thomasbm2> hasTopic <http://sandy.com/bookmarks.rdf#thomastopic1> . <http://sandy.com/bookmarks.rdf#bm1> recalls <http://foo.org/peardoc> . <http://sandy.com/bookmarks.rdf#bm1> hasTopic <http://sandy.com/bookmarks.rdf#thomastopic1> . <http://sandy.com/bookmarks.rdf#bm2> recalls <http://sample.example.com/appledoc> . <http://sandy.com/bookmarks.rdf#bm2> hasTopic <http://sandy.com/bookmarks.rdf#thomastopic1> . <http://sandy.com/bookmarks.rdf#bm3> recalls <http://bar.org/peachdoc> . <http://sandy.com/bookmarks.rdf#bm3> hasTopic <http://sandy.com/bookmarks.rdf#thomastopic1> .
Figure 8: Statements from Sandy's bookmark file in Figure 6 after publishing it on the Web.
When Thomas looks his current bookmark file and the one that Sandy published it is difficult to tell that some topics and bookmarks are the same. Furthermore, if Thomas decides to copy or merge Sandy's and his information we ran into possible conflicts again as the IDs are still relative.
We could also change the relative ID's absolute when publishing the bookmark file. This would help with the conflicts but leave the local files with the old definitions with no connection to the new.
Sara creates a local bookmark file "file://sara/bm/mexican.rdf" and adds a topic with ID "spicyfoods" in it. Now the ID of this topic resolves to "file://sara/bm/mexican.rdf#spicyfoods").
<r:RDF>
<r:Description r:id="spicyfoods">
<dc:title>spicy foods</dc:title>
<b:subTopicOf r:resource="#MyHomeTopic"/> .
</r:Description>
<r:Description r:id="bm1">
<b:recalls r:resource="http://mex.com/spicycurry"/>
<b:hasTopic r:resource="#spicyfoods"/>
</r:Description>
...
</r:RDF>
Figure 9: Excerpt from Sara's bookmark file "file://sara/bm/mexican.rdf"
Later Sara creates another bookmark file "file://sara/otherbm/indian.rdf" and wants to use the same topic "spicyfoods" in that file too. The relative ID for the topic is "../bm/mexican.rdf#spicyfoods", which resolves to "file://sara/bm/mexican.rdf/#spicyfoods".
<r:RDF>
<r:Description r:id="bm1">
<b:recalls r:resource="http://curry.com/spicycurry"/>
<b:hasTopic r:resource="../bm/mexican.rdf#spicyfoods"/>
</r:Description>
...
</r:RDF>
Figure 10: Excerpt from Sara's bookmark file "file://sara/otherbm/indian.rdf"
If we reorganize the files and move either the indian or the mexican bookmark file the reference to the spicyfoods topic needs to be changed. We could also use an absolute URI for the topic like in Figure 10. In this case a change is needed too but only when the mexican file is moved to another place.
<r:RDF>
<r:Description r:id="bm1">
<b:recalls r:resource="http://curry.com/spicycurry"/>
<b:hasTopic r:resource="file://sara/bm/mexican.rdf#spicyfoods"/>
</r:Description>
...
</r:RDF>
Figure 11: Sara's bookmark file "file://sara/otherbm/indian.rdf" when using an absolute URI for the topic reference
Sara meets her friend Sharon and as Sharon wants to share the indian.rdf bookmarks so Sara publishes them to the URI "http://www.foods.com/otherbm/indian.rdf" so that they can share shared it. She does not publish the mexican bookmark file as Sharon is not interested in that and she wants to do more work on that before wanting to share it. Furthermore, when she finally publishes this file it may not be located exactly in the same hierarchy in the Web as it located in her local computer.
<r:RDF>
<r:Description r:id="bm1">
<b:recalls r:resource="http://curry.com/spicycurry"/>
<b:hasTopic r:resource="../bm/mexican.rdf#spicyfoods"/>
</r:Description>
...
</r:RDF>
Figure 12: Sara's bookmark file published on "http://www.foods.com/otherbm/indian.rdf" when using a relative URI for the topic reference
After publishing the indian bookmark file all the bookmarks and topics in the global indian.rdf file will have base "http://www.foods.com/otherbm/indian.rdf" . However, the topic ID "../bm/mexican.rdf/#spicyfoods" is a bit problematic as there is no such a topic in location "http://www.foods.com/bm/mexican.rdf#spicyfoods" because currently Sara has no intention to publish the mexican bookmark file. Furthermore, another user may accidently publish a file "http://www.foods.com/bm/mexican.rdf" that has nothing to do with bookmarks, foods our topic but may still use the "spicyfoods" ID.
We do not want to change the URIs unless absolutely necessary. However, to avoid the above problem we may copy the local topic to the published indian.rdf file and refer to "http://www.foods.com/otherbm/indian.rdf#spicyfoods" instead of referring to "http://www.foods.com/bm/mexican.rdf#spicyfoods" that does not exist.
<r:RDF>
<r:Description r:id="spicyfoods">
<dc:title>spicy foods</dc:title>
<b:subTopicOf r:resource="#MyHomeTopic"/>
</r:Description>
<r:Description r:id="bm1">
<b:recalls r:resource="http://curry.com/spicycurry"/>
<b:hasTopic r:resource="#spicyfoods"/>
</r:Description>
...
</r:RDF>
Figure 13: Sara's bookmark file published on "http://www.foods.com/otherbm/indian.rdf" with a copy of the topic spicyfoods definition
In this case, we will loose the connection to the original topic in the local bookmark files unless we go through all of them and find "../bm/mexican.rdf/#spicyfoods", "file://sara/bm/mexican.rdf/#spicyfoods" or other paths to the same ID in all other local bookmark files and change them to refer to this new topic "http://www.foods.com/bm/indian.rdf#spicyfoods". But we preferred to not change the local files if possible.
Sara might have ID "spicyfoods" in many other local files identifying an resource that is not the same resource as the "mexican.rdf#spicyfoods" topic. In this case we would have the same problem as in Section 3.5 when collecting metadata from different sources and merging it together.
We can use UUID URNs instead of relative HTTP URLs to keep the IDs for the bookmarks and topics unambiguous. For instance, we can take Thomas' bookmark file "file://localhost/bookmarks.rdf" shown in Figure 1 and change all the relative URIs to unambiguous URNs as shown in Figure 15.
There are several ways to generate the UUIDs. For instance, we may serialize them as ntriples and use SHA-1 for the result. The existence of bnodes dictates that the not all isomorphic graphs will generate the same hash, but all identical hashes are products of the same graph, so long as the serialization language is consistent.
<r:RDF>
<r:Description r:about="urn:uid:bbbbtopic1">
<dc:title>fruitinfo</dc:title>
<b:subTopicOf r:resource="urn:uid:aaaaMyHomeTopic"/>
</r:Description>
<r:Description r:about="urn:uid:xxxxbm1">
<recalls r:resource="http://sample.example.com/appledoc"/>
<b:hasTopic r:resource="urn:uid:bbbbtopic1"/>
</r:Description>
<r:Description r:about="urn:uid:wwwwbm2">
<recalls r:resource="http://demo.example.com/orangedoc"/>
<b:hasTopic r:resource="urn:uid:bbbbtopic1"/>
</r:Description>
</r:RDF>
Figure 15: Part of Thomas' bookmark file in Figure 1 by using URN UUIDs.
Thomas' bookmark metadata in Figure 15 results into the statements in Figure 16. As the URNs are unambiguous there are no problems in conflicting with Sandy's or anybody elses bookmarks or topics.
<urn:uid:bbbbtopic1> title "fruitinfo" . <urn:uid:bbbbtopic1> subTopicOf <urn:uid:aaaaMyHomeTopic> . <urn:uid:xxxxbm1> recalls <http://sample.example.com/appledoc> . <urn:uid:xxxxbm1> hasTopic <urn:uid:bbbbtopic1> . <urn:uid:wwwwbm2> recalls <http://demo.example.com/orangedoc> . <urn:uid:wwwwbm2> hasTopic <urn:uid:bbbbtopic1> .
Figure 16: Statements from Thomas' bookmark file by using URN UUIDs.
The advantage of this solution is that we can easily create statistically safe URNs that are unambiguous and cannot be conflicted with other URIs. It is possible to find out if we are talking about a same topic or bookmark even after the bookmark file has gone through a complicated chain of e-mails and publishing operations.
The disadvantage of this solution is that we loose the ability to use HTTP
GET for the URN e.g. "GET urn:uid:xxxxbm1"
would not work. However, this does not make a difference before the file is
published because with local files it would not work anyway. Another problem
is that we may need to change the file when it is published as discussed in
Section 5.3.
We may not use URNs at all but instead insist that users always need to publish the bookmarks or topics before sharing them with others so that they can be given absolute HTTP URIs based on the URI of the bookmark store.
To prevent loosing the connection between the bookmarks and topics in the local, unshared file and the bookmarks and topics in the shared, published file all the URIs in the local files can be changed after the bookmark or topic has been published.
We have two problems.
When the bookmark resources are created they have a UUID URN ID. When they
are published to the Web they also get a HTTP ID. We need to be able to
define these two IDs for the same resource. This can be done by using the
owl:sameAs as shown in Figure 17.
<r:RDF>
<r:Description r:about="urn:uid:bbbbtopic1">
<dc:title>fruitinfo</dc:title>
<b:subTopicOf r:resource="urn:uid:aaaaMyHomeTopic"/>
<owl:sameAs r:resource="#topic1"/>
</r:Description>
<r:Description r:about="urn:uid:xxxxbm1">
<recalls r:resource="http://sample.example.com/appledoc"/>
<b:hasTopic r:resource="urn:uid:bbbbtopic1"/>
<b:hasTopic r:resource="#topic1"/>
<owl:sameAs r:resource="#bm1"/>
</r:Description>
<r:Description r:about="urn:uid:wwwwbm2">
<recalls r:resource="http://demo.example.com/orangedoc"/>
<b:hasTopic r:resource="urn:uid:bbbbtopic1"/>
<b:hasTopic r:resource="#topic1"/>
<owl:sameAs r:resource="#bm2"/>
</r:Description>
</r:RDF>
Figure 17: Adding HTTP URIs to Figure 15 before publishing the file in "http://thomas.com/bookmarks.rdf".
It should be easy to add this information without no changes to the
bookmark file. However, in practice it may be that many clients don't know
how to process HTTP address created by using owl:sameAsas shown
in Figure 17 so that we can use HTTP GET. There will probably be more clients
that can do HTTP GET with r:about definition.
Also the b:subTopicOf references should be changed to
published HTTP URIs when possible as otherwise it is hard to find the
information about the topic without a URN to HTTP URI mapping service. We may
still keep the URN reference as well and just add another topic like in
Figure 17. If the topic is in the same file we may use either full HTTP URIs
or fragment URIs, in which case subsequent moves of the file will change the
URIs to be relative to the location of the file. The URNs will still stay the
same.
Figure 18 presents another solution where we use with
owl:sameAs from the beginning for defining the URN address and
also always give a fragment HTTP URIs to bookmarks and topics. In this case
the fragment URIs should not be used locally as only the URNs are
unambiguous, but when the file is published we can convert to using them.
While we need to be careful about when to use the HTTP URI, the file does not
need to change except possibly for the b:hasTopic definitions
and we have more applications that can provide HTTP GET information.
<r:RDF>
<r:Description r:id="topic1">
<dc:title>fruitinfo</dc:title>
<b:subTopicOf r:resource="urn:uid:aaaaMyHomeTopic"/>
<owl:sameAs r:resource="urn:uid:bbbbtopic1"/>
</r:Description>
<r:Description r:id="bm1">
<recalls r:resource="http://sample.example.com/appledoc"/>
<b:hasTopic r:resource="urn:uid:bbbbtopic1"/>
<b:hasTopic r:resource="#topic1"/>
<owl:sameAs r:resource="urn:uid:xxxxbm1"/>
</r:Description>
<r:Description r:id="bm2">
<recalls r:resource="http://demo.example.com/orangedoc"/>
<b:hasTopic r:resource="urn:uid:bbbbtopic1"/>
<b:hasTopic r:resource="#topic1"/>
<owl:sameAs r:resource="urn:uid:xxxxbm2"/>
</r:Description>
</r:RDF>
Figure 18: Thomas' bookmark file with owl:sameAs links for UUID URNs.
Another possibility is to use dc:identifier for defining
alternative identifiers. However, it is not clear if there are any additional
benefits compared to owl:sameAs solution.
If we already have unambiguous URNs for identifying each bookmark or topic
resource it would be nice to reuse them to create unambiguous HTTP addresses
when a resource is published. We could embedd the UUID URN as part of the the
HTTP address , e.g. http://thomas.com/bookmarks#urn%3Atopic%3Aspicyfoods. We
cannot use the ":" character directly in the HTTP name (http://www.w3.org/TR/REC-xml-names/#NT-NCNameChar)
therefore we use "%3A". The bookmark file shown in Figure 14 is presented in
Figure 19 with embedded UUID URNs. The change of the b:hasTopic
references to relative HTTP addresses as shown in Figure 19 should be
unnecessary.
<r:RDF>
<r:Description r:id="urn%3Auid%3Abbbbtopic1">
<dc:title>fruitinfo</dc:title>
<b:subTopicOf r:resource="urn:uid:aaaaMyHomeTopic"/>
<owl:sameAs r:resource="urn:uid:bbbbtopic1"/>
</r:Description>
<r:Description r:id="urn%3Auid%3Axxxxbm1">
<recalls r:resource="http://sample.example.com/appledoc"/>
<b:hasTopic r:resource="#urn%3Auid%3Abbbbtopic1"/>
<owl:sameAs r:resource="urn:uid:xxxxbm1"/>
</r:Description>
<r:Description r:id="urn%3Auid%3Axxxxbm2">
<recalls r:resource="http://demo.example.com/orangedoc"/>
<b:hasTopic r:resource="#urn%3Auid%3Abbbbtopic1"/>
<owl:sameAs r:resource="urn:uid:xxxxbm2"/>
</r:Description>
</r:RDF>
Figure 19: Thomas' bookmark file in Figure 15 with embedded UUID URNs .
If we choose to use the embedded URN in the HTTP address we can create an easy rule for creating these HTTP addresses based on the published Web resource or the service URI and the URN. However, if we encounter a random URI it is impossible to know if this convention is used when it was created.
Query format would work in case we use a bookmark service e.g. http://thomasservice.com/bookmarks?topic=urn%3Atopic%3Aspicyfoods. However, it would be difficult to use it with a bookmarks file published as a Web resource. Also we would still need to define a standard way of forming the query URIs for them to be useful for all applications.
We would like to use HTTP addresses for naming the bookmarks and topics. Solution described in Section 5.2 where everything needs to be published before it can be shared or referenced from outside the file would let us do that. Unfortunately it is not always feasible as we are going to have users who do not have their own HTTP address base as a standard policy and therefore cannot create global unambiguous URIs whether they are offline or online.
We selected a solution by combining the solutions discussed in Sections 5.1 where a UUID scheme is used for local bookmarks, Section 5.2 where the bookmarks are published as soon as possible with a global HTTP address and Section 5.3 where the solutions for attaching both an HTTP address and a UUID URN to the same resource are discussed. We have not decided to combine solution in Section 5.4 where the UUID URN is embedded in the created HTTP name but that is still under discussion.
Section 5.1 discusses the use of UUID URNs to easily create IDs that are globally unambiguous and cannot be conflicted with other URIs. Figure 15 in Section 5.1 presents the first part of adopted solution where the UUID URNs are used as IDs for local bookmarks and topics.
The second part of the adopted solution is presented in Figure 18 in
Section 5.3. The file in Figure 15 is changed so that the HTTP URIs are
defined with r:id or with r:about depending whether we want to
use full HTTP URIs or fragment URIs that change if the file is relocated. We
also need to change all the occurrences of the published bookmarks or topics
referenced in the local files to keep them connected. Most of the time we can
add another reference to the new HTTP address without removing the URN
reference as demonstrated in Figure 18 with b:hasTopic.
Presented scenarios show that in some cases reliable generation or use of
plain HTTP IDs is problematic. Our current plan for a better solution
includes using UUID URN names for local bookmark resources. When the
resources are published they get an HTTP name as well as. Using the HTTP name
is always preferred when it exists. However, the HTTP name will be connected
to the UUID URN name by using owl:sameAs so that applications
understanding owl:sameAs should be able to know that they are
the same resource.
It is somewhat more work to include UUIDs but the only thing we loose compared to using only HTTP URIs is to be able to use HTTP GET when referring to a local bookmark or topic with a local URI. However, as these are local URIs, HTTP GET would not help much anyway. This solution helps to make reliable connections in cases when the user does not have an HTTP address yet and there are local references. In addition, local bookmark files may be sent by mail back and forth.
Finally, with this approach we can experiment with
owl:sameAs, which is a standard way that we can use to make
connections with the UUID URN address and the HTTP address.
[BookmarkSchema] Koivunen, M., Swick, R., Kahan, J., and Prud'hommeaux, E., An Annotea Bookmark Schema. http://www.w3.org/2001/Annotea/User/BookmarkSchema
[URI] URIs, URLs, and URNs: Clarifications and Recommendations 1.0, Report from the joint W3C/IETF URI Planning Interest Group, W3C Note 21 September 2001. http://www.w3.org/TR/uri-clarification/
@@[THTTP] Daniel, R. A Trivial Convention for using HTTP in URN Resolution. 1997. http://www.ietf.org/rfc/rfc2169.txt@@
Copyright © 1999-2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.