- From: Bruce D'Arcus <bdarcus@gmail.com>
- Date: Tue, 31 Jul 2007 13:06:36 -0400
- To: Danny Ayers <danny.ayers@gmail.com>
- CC: Garret Wilson <garret@globalmentor.com>, andy.seaborne@hp.com, bnowack@appmosphere.com, Harry Halpin <hhalpin@ibiblio.org>, Semantic Web <semantic-web@w3.org>
Danny Ayers wrote:
...
>> The family, given, additional properties are for pieces of full names.
>
> Ok, I see from
> http://tools.ietf.org/html/rfc2426#section-3.1.2
> it's a structured value, which it appears Norm reflected:
>
> Name
> given-name
> family-name
> additional-name
>
>> Norm restricted cardinality to 1 on these,
>
> How so?
>
> and so chose the first
>> approach. I strongly supported this move.
>
> Assuming the cardinality was restricted to 1, it wouldn't be possible
> to represent all vCards using this vocab since RFC2426 says: "Each
> component can have multiple values."
Clearly this perspective would advocate some practical interpretation of
the vCard spec, rather than following it precisely.
I see absolutely no practical value to doing:
vcard:givenName ("John" "Paul")
... over:
vcard:givenName "John Paul"
Garret disagrees.
>> Two doesn't work.
>
> Name
> given-name
> family-name
> additional-name
> additional-name
> ...
>
> I don't see why not, the Name node is acting as a quasi-container.
But the names are ordered. E.g. in my example above I presume the person
in question would go by "John Paul" rather than "Paul John".
>> Garret wants to allow something like the third approach.
>
> This seems unnecessary, multiple values are possible without there
> being a container or collection.
Indeed, but not if they're ordered.
>> This discussion is all about resolving this question.
>
> I'd be tempted to make vCard/RDF follow vCard closely and use other
> vocabs/structures where the modelling doesn't seem right.
>
> But anyhow I'd better duck out - I still can't face reading the dozens
> of earlier posts...
:-)
Bruce
Received on Tuesday, 31 July 2007 17:06:56 UTC