- From: David Powell <djpowell@djpowell.net>
- Date: Mon, 2 Apr 2007 15:59:14 +0100
- To: Garret Wilson <garret@globalmentor.com>
- CC: semantic-web@w3.org
Hi Garret, > David Powell wrote: >> Is there any reason why we can't just space separate multi-valued N >> components like this: >> >> [] rdf:type ex:N ; >> ex:familyName "Geldof" ; >> ex:givenName "Peaches Honeyblossom Michelle Charlotte Angel Vanessa" . >> > As I mentioned before, one certainly *can* do that, but if we do, what's > the point of RDF? Why don't we just stick everything in a single ex:N > literal value? In fact, why don't we just use normal vCard format---why > RDF? Note the problem: RDF can handle distinct properties just fine, but > has real problems with optionally plural values. That scares me > somewhat, as the use case here is neither complicated nor uncommon. I don't like values flipping from using a list syntax to a single value syntax depending on how many items there are. I guess that this leaves something like: <v:N> <v:givenName rdf:parseType="Seq"> <rdf:li>Peaches</rdf:li> <rdf:li>Honeyblossom</rdf:li> ... </v:givenName> <v:familyName rdf:parseType="Seq"> <rdf:li>Geldof</rdf:li> </v:familyName> </v:N> Always using a list structure for these values. A bit verbose, bit that's not such a huge problem is it? > I think the issue comes up more in family names than in given names. I > would think that we would want to distinguish that "van Buren bin Laden" > is actually two family names, "van Buren" and "bin Laden". OK, so space-separation of name items won't work. >> I guess that additionalNames doesn't necessarily have a correct >> position in the formatted name and is just a catch-all for >> everything else. > I would think that this is for what Americans call "middle names". OK, I was a bit unsure about whether additionalNames meant middle names from reading the RFC. I guess that it probably does, although it isn't stated explicitly. >> For addresses the intent is clearly for multiple items in each >> sub-component to represent multiple lines in the address, so why not >> just represent them as a line-feed separated value? > It is certainly possible to do that. But again, is RDF so impoverished > that we have to define a sub-syntax? "This field uses spaces to separate > values. This other field uses LF to separate values. But remember to > collapse CRLF into a single LF, and consider a single CR to be > syntactically incorrect. Oh, and don't forget a / to indicate a > continuation of a next line, unless of course we encode the / > somehow..." Didn't we move beyond all that once we got into the RDF data > model? Are we going to define entire new grammars just to get stuff out > of Directory vCard into RDF? That's the problem I have with this sort of > thing, although it is certainly possible. vCard addresses aren't ideal, and are a bit US-centric. If you wanted to search for people on a given street, then you are already going to have to hunt around in streetAddress to guess where the house number or name ends, and the street starts (or vice-versa in Europe) - and whether house names are on a separate line or not. Is it any harder to find people from a certain village if they are represented as: <v:streetAddress>1 High Street, Village</v:streetAddress> than: <v:streetAddress rdf:parseType="Seq"> <rdf:li>1 High Street</rdf:li> <rdf:li>Village</rdf:li> </v:streetAddress> ...? What about if the streetAddress consisted of 3 components, perhaps the name of a block of flats on a street. There isn't a single place to look for the value as it is, so maintaining the separation in the RDF isn't that important. If you were using a richer address vocabulary, like this one: <http://rdfweb.org/topic/AddressVocab>, then searching would work better, but vCard isn't rich enough to avoid heuristics and guesswork. [It would be nice if you could enrich vCard/RDF addresses with an S42-3 level of information, but it looks like that would be difficult.] I was thinking that as vCard addresses aren't at all semantically tidy, then there is little that you can do with multi-item components other than concatenate them with newlines for display. I suppose this isn't entirely true with something like HTML, where having separate items makes it marginally easier to create multiple <div> tags or whatever for display - but that seems like a fairly minor advantage. -- Dave
Received on Monday, 2 April 2007 14:59:38 UTC