[rdfweb-dev] Proposal: Names in FoaF

Morten Frederiksen mof-rdf at mfd-consult.dk
Sun Apr 20 23:38:42 UTC 2003


On Sunday 20 April 2003 19:04, Dan Brickley wrote:
[snippage]
> Probably the best way we can avoid going too meta on process is to focus on 
> specific examples and goals. I tried to write up one just now in [4], based
> on the (previously unarticulated?) goal of roundtripping my name
> information between FOAF and other more person-centric representations, in
> particular LDAP and vCard.
That is an interesting use case, one that I somewhat anticipated, and feel 
should be possible with the proposed approach.

> Coming back to your specific proposals, let me see if I understand
> correctly. Is the idea that we focus on use of foaf:name (with flat
> string values) for the basic preferred form of someone's name, while also
> providing an account (via a list indicated by sortName) into the
> compositional sub-structure of that name? So we have RDF classes for the
> various kinds of name component, and these are related only indirectly to
> the named person because we want to preserve the ordering information too.
That's roughly it.

> How would this work with me? My general name is 'Dan Brickley' (although
> firstname formally is 'Daniel', but more people call be 'DanBri' than
> 'Daniel Brickley' :). My unused middlename is 'Alexander'. I'd like
> (for LDAP/LDIF/vCard import/export) to be able to record that
> (which would require a new class?), without it implying or suggesting that
> my name ought to be written 'Dan Alexander Brickley'...
This is where the display name, foaf:name, should prove useful.

The point of the proposal was to provide a means for the most used "meta" use 
cases - displaying and sorting (and searching, if one wanted to find those 
whose "last name" was perhaps "Beck", but not the ones with that as a "first 
name").

As stated in the proposal, the non-IRC nick name is a troublesome issue, it's 
really a different version of a given name, and perhaps could even be 
modelled as that, like a foaf:thumbnail property of a foaf:Image:

<foaf:Person>
  <foaf:name>Dan Brickley</foaf:name>
  <foaf:sortName rdf:parseType="Resource">
    <rdf:li><foaf:FamilyName rdf:value="Brickley"/></rdf:li>
    <rdf:li>
      <foaf:GivenName rdf:value="Daniel">
        <foaf:shortName rdf:value="Dan"/>
      </foaf:GivenName>
    </rdf:li>
    <rdf:li><foaf:GivenName rdf:value="Alexander"/></rdf:li>
    <rdf:li><foaf:HonorificTitle rdf:value="Mr."/></rdf:li>
  </foaf:sortName>
</foaf:Person>

Other than that, I'm quite open to suggestions on how to model those kinds of 
nick names (which I feel should be seperate from IRC nicks, even though they 
sometimes overlap).

> I'm in two minds with the sortName/list construct. Indicating the
> substructure of the name seems handy, and for that ordering is needed;
> however the intermediate nodes complicate the task of finding out
> relatively basic things. For eg., retrieving my middlename would require
> navigating from my person node to my sortnode list then testing each of
> its members to see if they were of rdf:type foaf:MiddleName (if such a
> construct were included).
Ignoring the middle name issue for a moment, it still seems like a mechnial 
and deterministic operation to find a specific component of a name.

However, I can't really disagree with the complexity issue, especially of the 
syntax, but I don't see a way around it, I've tried...

Regarding the problem of middle names, if that's such an important issue 
(most people never use them, the rest are often abbreviated), it seems as if 
it would be necessary with yet another sequenced property, "natural order"...

> I do agree that foaf:name provides the island of sanity in all the
> confusion and complexity surrounding naming, maybe we could be clearer
> about that part of FOAF being considered more stable that the rest of the
> naming vocab?
That would be fine with me, and perhaps separating it into a foafname 
vocabulary would be the best way of doing that.

> Another thought: we could be more explicit about using
> rdfs:subPropertyOf when cleaning up the redundancy in the current
> vocabulary, eg. between surname and lastname, so that existing content
> didn't become outlawed.
I really think the western focus should go, before FoaF gets deployed more 
widely. I'd hate for FoaF to become yet another vocabulary that dodged the 
issue, like everyone else, and just assumes everybody fits the western style.

> But that would, on my reading of your proposal,
> mean keeping the property-oriented representation, ie. relations (of
> various kinds) between people and the strings that are part of their names.
> Do you think that could be made consistent with the class oriented
> representation you propose?
I'm not sure I know what you mean with this, but yes, another approach would 
be to have literal-valued properties like the current ones (but without the 
western angle), and instead add a literal foaf:sortName property:

<foaf:Person>
  <foaf:name>Dan Brickley</foaf:name>
  <foaf:nick>danbri</foaf:nick>
  <foaf:sortName>Brickley, Dan</foaf:sortName>
  <foaf:givenName>Daniel</foaf:givenName>
  <foaf:givenName>Alexander</foaf:givenName>
  <foaf:familyName>Brickley</foaf:familyName>
  <foaf:nickName>Dan</foaf:nickName>
</foaf:Person>

As can be seen, there's more redundancy, and there are problems for people 
with several given names (e.g. which one does the nickName refer to?) - one 
that won't be solved by adding a foaf:middleName property subclassed of 
foaf:givenName, since some people have more than two given names.

Aside: The Danish word for "nick name" can roughly be translated into "pet 
name"...

> Sorry for lack of consise thoughts on this topic! Maybe rdfweb-dev folk
> could contribute some more non-western name examples (here or in the Wiki
> at [4]) so we can try writing up some full examples, see how they look...
I tried finding some good examples of, say, chinese names, but it's hard to 
understand...

The DC note does have some meta-examples, like "<fathers name> <given name>", 
perhaps they could help?


Regards,
Morten



More information about the foaf-dev mailing list