W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > August 2006

Re: [BioRDF] global uniqueness requirement of LSIDs and RDF

From: John Barkley <jbarkley@nist.gov>
Date: Mon, 14 Aug 2006 06:30:32 -0400
Message-ID: <004b01c6bf8c$abcaa930$8a3a0681@ncsl.nist.gov>
To: "Miller, Michael D \(Rosetta\)" <Michael_Miller@Rosettabio.com>, <public-semweb-lifesci@w3.org>
Cc: <jbarkley@nist.gov>

hi Michael,

> How I've come to think about this is that some properties are intrinsic
> to the type of record, for a person, perhaps their SSN if American, and
> some are not, such as a person's age.  But even this becomes context
> dependent if one wishes to track the state of the person once a year.

If I understand the uniqueness requirement of LSIDs, then a new LSID for
"Michael Miller" must be created every year when the age property changes.

jb



----- Original Message ----- 
From: "Miller, Michael D (Rosetta)" <Michael_Miller@Rosettabio.com>
To: "John Barkley" <jbarkley@nist.gov>; <public-semweb-lifesci@w3.org>
Sent: Saturday, August 12, 2006 5:38 PM
Subject: RE: [BioRDF] global uniqueness requirement of LSIDs and RDF


Hi John,

Another version of this problem has existed in the relational world when
importing records from the outside world, which is 'when should an
existing record be updated and when should a new record be created.'
Because the record is coming from the outside world, an alternative key
must be used to see if it already exists, that is, some subset of the
record's properties.

How I've come to think about this is that some properties are intrinsic
to the type of record, for a person, perhaps their SSN if American, and
some are not, such as a person's age.  But even this becomes context
dependent if one wishes to track the state of the person once a year.

The fact that you only have one property for each of your objects
probably oversimplifies the problem.

cheers,
Michael

> -----Original Message-----
> From: public-semweb-lifesci-request@w3.org
> [mailto:public-semweb-lifesci-request@w3.org] On Behalf Of
> John Barkley
> Sent: Tuesday, August 01, 2006 5:31 AM
> To: public-semweb-lifesci@w3.org
> Subject: [BioRDF] global uniqueness requirement of LSIDs and RDF
>
>
>
> The global uniqueness requirement of LSIDs is clear if one is
> talking about
> something like an image. As we discussed on yesterday's
> telecon, if one bit
> in an image is changed, then the LSID must change. My
> question is how does
> this work with an LSID that dereferences to RDF. Consider the
> following
> simple examples:
>
> 1. Suppose in my namespace I create lsid-A in an RDF file
> where lsid-A has a
> single datatype property. Following the global uniqueness
> requirement, if I
> change the value in that datatype property, then I have to
> create a new
> LSID.
>
> 2. Now suppose I create another LSID, lsid-B, that has a single object
> property whose object is the lsid-A from (1). Once again, if
> I change the
> value of lsid-A's datatype property, then I have to create a
> new LSID for
> lsid-A, and also, depending on the meaning I want for lsid-B,
> a new LSID for
> lsid-B with object property the new lsid-A.
>
> 3. Now suppose that I create lsid-C with a single object
> property whose
> object is url-A, also in my namespace. url-A has one datatype
> property. What
> should happen if I change the value of url-A's datatype
> property?  Do I need
> to create a new LSID for lsid-C? I would think the answer
> would be yes.
>
> 4. In (3), url-A is in my namespace. What should happen if
> url-A is not in
> my namespace and the value of its datatype property changes?
>
> Putting these questions more generally:
>
> 1. For RDF, does the global uniqueness requirment mean that only the
> immediate set of properties and their object names/values
> need be unique?
>
> 2. Does it mean that, for RDF, an LSID's closure (of any
> kind) within the
> namepace that I control need be unique?
>
> 3. With RDF, do I have to be concerned about an LSID's
> closure (of any kind)
> in other peoples' namespaces?
>
>
> thanks,
>
> jb
>
>
>
>
>
Received on Monday, 14 August 2006 10:31:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:44 GMT