Re: [vcard] multiple names, multiple address lines

Garret,

> First, in my opinion rdf:Seq is antiquated, but we can talk about the
> same thing in terms of rdf:List.

Yeah me too, usually, but in this case I shied away from adding all
those extra triples and bnodes.

> Sure, "value-flipping" is untidy. But that's not a fault of our 
> design---it's a fault of the design of RDF. We won't be able to get past
> it, and there are going to be many things, not just in vCard, but in 
> many real-world ontologies. But we can't choose to put an rdf:List 
> everywhere, because in many cases rdf:List is the exception, not the 
> rule. So yes, I think having a list for all values is a huge problem. 
> And while we may not like "value-flipping" from a tidiness or elegance
> point of view, I think it's the lesser of all these evils, giving us:

>     <v:N>
>       <v:givenName rdf:parseType="Collection">
>         <rdf:Description rdf:value="Peaches"/>
>         <rdf:Description rdf:value="Honeyblossom"/>
>         ...
>       </v:givenName>
>       <v:familyName>Geldof</v:familyName>
>     </v:N>

> An inconsistent syntax and even an inconsistent data model 
> representation, I know, but that's what we're stuck with. Damn you, RDF!

I don't know enough SPARQL to be able to query this. I assume that it
can be done. It doesn't seem very query-friendly though.

Not a common problem, but value-flipping would be ambiguous if you
were working with lists of lists, rather than lists of literals.

>> 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.
>>   

> Your point about the poorly defined semantics of multiple address line
> separation is well-taken, although it is important that the separation
> be preserved somehow.

> So it seems that really the big sticking point here is the vcard:N 
> subproperty issue. I would claim that the problem lies not in vCard nor
> in our proposals, but rather in the design of RDF which will be biting
> us all for years to come.

Lists are difficult to model satisfactorily. The only way that I can
imagine the situation being better in RDF is if RDF had a native list
type. Like a type of literal, that was a single resource that could
hold references to one or more literals, bnodes, or uris.

You can /almost/ do this without any changes to RDF though. It wont
work for bnodes, but you can stuff multiple URIs or Literals into a
Literal. It is really a more generic version of what I was proposing
by newline-separating address component lines.

[Literals, are even more of an obstacle to extensibility. If I was RDF
King, then Literals wouldn't exist and instead we'd have bnodes with
an intrinsic label so that we could use them as subjects, and you
wouldn't need to worry about them being dead-ends when used in
vocabularies...]

> I propose that "value-flipping" is the least inelegant of the
> inelegances, but I'll keep thinking about it.

A crazy experimental option would be to implement atomic resource
lists by using an XML literal fragment:

<l>Peaches<l><l>Honeyblossom</l>

Can any SPARQL implementations run XPaths over XML Literals?

As it is just a fragment, you could get away with parsing the XML even
if you didn't have an XML parser, you'd only have to worry about
entity character references and CDATA.

... but I wouldn't do that.


I seem to remember seeing some vCard implementations use line feeds to
separate street addresses.  I think vCard 2.1 (which is widespread)
works that way, at least.  And as newlines are semantically equivalent
to lists for these fields; as most UK addresses contain multiple
street lines; and as there is no real semantic significance to how
each street sub-component might be positioned in the list - I'd favour
newline separation for address sub-fields.

I'm undecided about N fields. value-flipping is more work for
consumers, producers, and editors - and only serves to save a few
bytes and triples. As an "optimization", will it cause more problems
than it solves? So, I guess I'd prefer just using lists exclusively.
Although I admit that it introduces a lot of extra triples (1n per
sub-field if you use rdf:Seqs, 2n for rdf:Lists)

-- 
Dave

Received on Monday, 2 April 2007 16:59:12 UTC