- From: Bill de hOra <bill@dehora.fsnet.co.uk>
- Date: Mon, 12 Feb 2001 22:32:03 -0000
- To: "Mark Grossman" <msg@geocast.com>, "David Megginson" <david@megginson.com>
- Cc: <www-rdf-interest@w3.org>, <xmlschema-dev@w3.org>
>> There are two things that somewhat ameliorate this problem: 1) You don't absolutely need a unique identifier for something, you can use an unambiguous reference in some accepted namespace. Just because you dont have someone's U.S. Social Security number of an encoding of their thumbprint doesn't mean you can't disambiguate them. 2) Through the miracle of descriptions, you can hone in on something's identity. My name is fairly common, but augmented with my date and place of birth, I can be uniquely identified. >> You can't, with absolute certainty, ensure that a mistake was not made in the chain of events that identify someone from cradle to grave and that for some system that person will not be confused with another person. This is real Real World stuff and Real Lives get destroyed over such errors. Where lives are at stake, a lot more is needed than a birth cert and a postcode. SSNs, Birth Certs and the like, are sometimes called SUIDs (Supposedly UIDs) and with good reason. SSNs in particular have rich history of being abused as semantically overloaded identifiers: a process not at all unlike conflating identifiers with retrievable resources. Potentially SUIDs are ok for identification, on the assumption that the relevant systems have accurate data (very big assumption); they are useless and dangerous in some cases for authentication, ie a positive identification, (which is distinct from a negative identification). We can't guranteee uniqueness and data integrity across databases any more than we guarantee the absence of defects in software: now and then you need to go out of band to be sure the identity decision is indeed valid. I don't see what a URI adds to a UID that makes it more than supposedly unique. Bill de hOra
Received on Monday, 12 February 2001 17:32:36 UTC