W3C home > Mailing lists > Public > semantic-web@w3.org > July 2007

Re: Can you query rdf:List easily? (WAS Re: update on vCard edits and The Compromise)

From: Bruce D'Arcus <bdarcus@gmail.com>
Date: Mon, 30 Jul 2007 08:00:11 -0400
Message-ID: <46ADD2CB.102@gmail.com>
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.

Received on Monday, 30 July 2007 12:00:05 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:01 UTC