[rdfweb-dev] foaf:Person identification

Jim Ley jim at jibbering.com
Mon Jan 12 12:34:03 UTC 2004


"Mike Higginbottom" <mike at peak41.co.uk>
>On Fri, 9 Jan 2004 22:24:34 -0000, Jim Ley <jim at jibbering.com> wrote:

>Why is it easier to give people a URI instead of a GUID?

It's equivalent to my mind, but a URI is a lot more useful in RDF as it
simplifies things greatly, and if there is a single identifier for a person,
a URI makes a lot more sense than a GUID.

> In these
>situations using a GUID becomes much more straightforward doesn't it?

Using a GUID is not straightforward, you need to have access to an accurate
GUID of a person before you can talk about them, that's a ridiculous
constraint.

>OK, that's a fairer description, and it seems like a good idea but I can't
>help feeling it's a little 'wooly'.

The concrete is unworkable without a central resource, central resources
have all sorts of problems.

>> Which would be fine, except it brings lots of problems, and is
>> unworkable,
>> for all sorts of reasons.
>I think this is the nub of the issue.  I don't understand what these
>problems are :(

Finding out a GUID of a person, talking about someone when you do not have
enough information about them to identify their GUID, talking about a person
when they've not yet generated a GUID for themselves, talking about dead
people who cannot generate a GUID for themselves, having to search the
entire universe looking for people to identify the GUID, creating a central
authority for generating GUIDS and associated maintenance of it.   Are just
a few of the problems.

>Agreed, but do you think it needs to work worldwide with absolutely no
>ambiguity or just with a real world human interpreted uniqueness.

If it's not going to be worldwide unique, then we don't need to worry about
issues of people who might re-use email addresses, and I don't see much
point in having a GUID that's not global.

>I didn't word that very well.  I really meant that the app gives you a
>list of all the danbris it knows about.  If the one you're thinking about
>isn't in the list (eg he has no FOAF file) then he just gets ID'd as
>Danbri.

So I can't talk about someone in two places, unless the app knows about that
persons unique ID - even if  I don't know the real identity (GUID) of
danbri, it's still useful to me to know that the person in one photo is the
same person as in the other one.

>Obviously you can't assign a GUID to him yourself, that has
>to be done by the subject.  Is this one of the problems you're referring
>to?

Of course, not being able to say anything about someone until they've
generated themselves a GUID is ridiculously unworkable.  Am I going to have
to regenerate all my metadata after he's done it for example.

>> As a back end thing, I'm  _:genid1_R1072397830234  completely
>> unambigiously identifies me
>Why does that completely and unambiguosly identify you?

Because I say it does, that ID is a GUId within my universe.

>What generated
>that?  What's to stop the same ID being generated for me?

my GUID generation code.

>  If it does what
>you say then surely it's a GUID and my proposal is already in place isn't
>it?

No, because it's only system wide, it cannot go outside the system into the
real world without the above problems coming into play - you'd have to come
to me to get a GUID before you could talk about me, or even yourself.

>As for what you'd want to do with it, well specifically I could, for
>example, use it to assume (but obviously not prove) that the Jim Ley this
>bit of data refers to is the same Jim Ley that wote this mail.

Much easier to use a suitable definition of mbox sha1sum surely? It doesn't
prove anything anyway, a GUID is no less fallable than an email address or
weblog or DNAChecksum even.

> More
>generally, a unique identifier is just a useful property to have in
>systems.

Within systems is sure is, which is why I have one, I'm sure every other
foaf consumer has one too, but that doesn't mean it's sensible to extend it
outside the system.

Jim.




More information about the foaf-dev mailing list