Re: yet another RDF vCard

Garret,
    I think the problem is I haven't seen your proposal. Could you
e-mail it to me or post it to
semantic-web@w3.org? That may be why we crossed-wires.

Since I hadn't seen your proposal I was just responding to the fact that
the current spec would likely prefer one to use:
<v:sort-string>Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.</v:sort-string>
instead of  <v:n>Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.</v:n>,
since, as you pointed out, "v:n" is for components of a name, not
strings per se, so its range is members of the v:Name class.

I don't see any problem with your proposal and agree with what bit of it
I've read.

 Is your point that you would prefer

<card:N><card:firstName>George</card:firstName></card:N>

i.e. using card:N as a class rather than our current use of v:n as a
property?

Currently we would accommodate that sort of thing by having a URI
(possibly blank node) for the name itself (similar to your usage of
card:N).

 http://www.example.org/person v:n www.example.org/example_name.
 http://www.example.org/example_name a v:Name.
 http://www.example.org/example_name v:given-name "George".

ala sort of


<v:n><v:Name><v:given-name>George</v:given-name></v:Name> </v:n>

The main problem I see is that  since v:given-name currently has a
restricted cardinality in v:Name, so one could not right now put a
collection of statements there as your example. However, I do agree
that  these complex names are good things and that the parsing rules you
put forward would be necessary to parse these complex names, so we can
(I assume you've noted this) have to get rid of cardinality constraints
currently in the spec.

One question is to keep v:n as a property or make it a class.

Since we currently have a v:Name, I think it's fine to keep v:n as a
property.

 However, I do think that we should get rid of the cardinality
constraints and put in Garret's rules (or something very similar) into
the spec.

What do people think?

>   To put that last point another way, a processor should know, just by
> following the specification, how to generate a traditional vCard from
> any RDF vCard data solely from the specification. I think the current
> http://www.w3.org/2006/vcard/ns has the former problem. I think your
> new solution has the latter---or maybe I didn't understand it correctly.
>
> Garret
>
+1, but it does make things harder :)


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Tuesday, 27 March 2007 22:53:02 UTC