Re: frad:Person and foaf:Person

On Mon, Nov 1, 2010 at 1:01 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> Quoting Dan Brickley <danbri@danbri.org>:
>
>
>>
>> Is the distinction one concerning the 'things in the world', or more
>> about their actual descriptions in some particular record?
>
>
> Dan, this is one of those areas where the library cataloging view is very
> particular but also very different from the SemWeb view. First, I suggest
> taking a look at the diagrams that Gordon pointed us to:
>
> http://www.gordondunsire.com/pubs/docs/frdiagrams.pdf
>
> You will see there that names of things are first class objects in the
> library world. The reasons for this are historical (not hysterical)[..]

Thanks for confirming my reading!

I think the big difference w/ the SemWeb world isn't so much around
names, but around the idea of these standards all being used alongside
each other in opportunistic mix-and-match combinations. That goes
against many people's ideas of what a data standard amounts to, not
just in the library world.

Ok so on this topic of names, I long wanted a class in FOAF that
stands explicitly for someone's name. The reasons for this I hope are
also not hysterical, just pragmatic. Sometimes people have several
names, and unless those are modeled as 'things in themselves', it is
hard to keep their properties clearly separate. In particular I'd like
to be able to add pronunciation information (using media files, and/or
http://en.wikipedia.org/wiki/International_Phonetic_Alphabet) and
possibly dates. (Genealogy apps might also want to treat names as
first class things with information about their meaning, associated
geography etc.).

So why doesn't FOAF have a class whose instances are human names?

 (Just for now let's set aside Groups, Organizations, Projects and
other Agents just as pedigree pets! all these deserve names too).

The answer might be hysterical, it's certainly silly. Why? we just
couldn't think of a good name for it, or for the main person-to-name
relation.

We already had 'foaf:name' that links a person to a textual form of
the name, so we couldn't use that. If there was a class let's say
'foaf:NameDetail' (to avoid a class and property's id differing only
in capitalization), and a linking property e.g. 'foaf:nameInfo', then
any person could be linked tidily to multiple descriptions of names,
and each of those might have dates (eg. a post-marriage name, or a
post-moving-to-USA name), pronunciation, alternate spelling etc.

I'm not sure NameDetail and nameInfo quite work as (er...) names, but
maybe they're bearable.

BTW as discussed here recently, SKOS has some related facilities; in
fact SKOS's labelling machinery is useful as a general purpose 'escape
hatch' wherever the RDF vocabulary world hasn't modelled some area in
detail. I hope foaf:focus helps people exploit it this way. But that
said, I do think names are in fact worth modelling explicitly. They're
just so hard to do right (internationally etc.), that for years re
FOAF it was too intimidating a problem to address at all (see
fascinating links below).

So  - we relied mostly on a single flat text/markup string, foaf:name,
plus half-hearted variants on familyName and givenName. But perhaps
adding a *class* for a name is a nice next step as it would allow
other parties to attach their own properties while sharing some common
structure?

cheers,

Dan

ps. via http://www.delicious.com/danbri/names

http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
http://blog.jclark.com/2007/12/thai-personal-names.html
http://rishida.net/blog/?p=100

Received on Monday, 1 November 2010 08:15:06 UTC