W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > January 2007

RE: Unique ID options

From: Eric Neumann <eneumann@teranode.com>
Date: Mon, 29 Jan 2007 12:52:17 -0500
Message-ID: <A3970D83EC72E84B8D2C2400CD6F0B9FE9B1EE@MI8NYCMAIL16.Mi8.com>
To: "Matthias Samwald" <samwald@gmx.at>, public-semweb-lifesci@w3.org
cc: public-hcls-dse@w3.org


The key item to remember in this discussion is that 'Observations' as well as Trial 'Subjects' and 'Studies' need solid URIs, and as you and Chimezie point out, there are different strategies. In our task, we want to guarantee that any opbservation can be referenced later for downstream (retrospective) analyses and annotations.

The secondary issues here is whether to make URI's opaque or not, and for the prupose of examples and demos, it seems to help making the URI 'self-explanatory' for now. In the case provided by Kerstin there is a second dependency embedded in the URI: each Observation MUST be unique to a particular study AND subject (i.e., cartesian product of both in the URI), hence the concatenated pathname to make this explicit. 


-----Original Message-----
From: public-semweb-lifesci-request@w3.org on behalf of Matthias Samwald
Sent: Mon 1/29/2007 12:32 PM
To: public-semweb-lifesci@w3.org
Subject: Re: Unique ID options

> Well, I'm inclined to ask why URI's should be explicitely assigned?

We had a discussion about blank nodes on a teleconference some months ago:

bNodes don't serve as a replacement for URIs for cases where you cannot decide on assigning a URI. They behave somewhat different than one might think, e.g. in a SPARQL query.
Another obvious reason for assigning URIs instead of bNodes is that URIs are essential for making connections between distributed datasets, which is one of the main arguments for using Semantic Web standards. Even if you are sure that your ressource is of no interest for anyone besides yourself at the time you are creating it, this might still change later on. 

-- Matthias
Received on Monday, 29 January 2007 17:53:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:22 UTC