- From: Bruce D'Arcus <bdarcus@gmail.com>
- Date: Mon, 30 Jul 2007 08:00:11 -0400
- To: Danny Ayers <danny.ayers@gmail.com>
- CC: andy.seaborne@hp.com, bnowack@appmosphere.com, Garret Wilson <garret@globalmentor.com>, Harry Halpin <hhalpin@ibiblio.org>, Semantic Web <semantic-web@w3.org>
Danny Ayers wrote: > I'm late to the thread, so apologies if this has been covered already: > > Harry's data, reworked to use literals, would look something like: > > _:lola > vCard:additionalNames ( "Edward" "Reeves" ) . > > - the object here is a list, so the plural-named property seems reasonable. > > Similar information could be conveyed as: > > _:lola vCard:additionalName "Edward" ; > vCard:additionalName "Reeves" . > > (or similar, intermediated with an rdf:Bag) Just to remind people, Norm made what I consider to be the right decision on names originally: restricting the cardinality of the name parts to 1. That's pragmatic: simple to encode, to convert in and out of the hCard microformat, and simple to query. It's exactly the kind of thing that the RDF world needs to be doing more of. As Tim said in response to Garret's suggestion that names are brain-dead simple, they are not; they're really complicated in a lot of cases! To believe that breaking it all apart and preserving order is some kind of magic bullet it misguided. If you have a relational database, how sensible is it really to have a separate table for name parts, where each and every token is a separate row? So I think WRT to where to go now, I really think we need to keep the original notion that Norm had: singular namepart properties with a cardinality of 1. If we need to make the painful decision to add duplicate plural name part properties, so be it. I dislike the idea regardless of whether we use Seq or List, but I don' think what I hope will be a short-term limitation in SPARQL will be the final decider. Bruce
Received on Monday, 30 July 2007 12:00:05 UTC