Re: yet another RDF vCard

Harry,

Harry Halpin wrote:
> However, the way we decided to deal with this was simply to use v:name
> to deal with the whole name, and keep "v:n" for the "components" of a
> name,

I'm not sure I understand. Do you mean v:name property or v:Name class? 
v:n property or v:N class? Because right now, the specification has v:n 
property with a range of v:Name class, which makes sense. But what you 
say next...

> but not put an xsd:string as the range - and this maps to the use
> of vcard in the hcard microformat as well.

xsd:string as a range of what? If I take what you say literally, you now 
are using a v:name property that has a string range, and a v:n property 
that has an undefined range---is that it? Or are you saying that you're 
keeping the v:n property v:Name range relationship, and the components 
of v:Name have an undefined range?

Either way, this moves from a format that is so restrictive that it 
can't handle real-world data (i.e. unacceptable for publishing) to a 
format that is so unrestricted that it can't be understood by a general 
processor (i.e. unacceptable for consuming). In other words, if anything 
can be put in the range of given-name, for example, then only the thing 
that produced it will know how to extract the information from it.

That's why the proposal I listed last time tries to walk the line 
between so much restriction to be of any use, yet so much freedom that 
the processor doesn't understand it. Let me list the relevant rules 
again from my proposal:

    If a particular Directory type calls for a literal value yet 
specifies parameters for that value, or if a literal value appears in 
some other circumstance in which an RDF resource is necessary (such as 
as elements of rdf:List), a blank node shall be used as the property 
value with the literal value appearing as the property of the blank 
node's rdf:value property. e.g. The vCard ORG type, if language needs to 
be specified, would produce an vcard:org property with a blank node 
value that has both the directory:language property to indicate the 
language and also the rdf:value property to indicate the literal 
property value.
    If a particular Directory type specifies a structured value, an RDF 
class shall be used to contain the elements of that stuctured value with 
a name in the form example:InitialUppercase. e.g. The value of the vCard 
ADR type would be represented as a vcard:Adr class that is the value of 
a vcard:adr property.
    If a particular Directory type specifies a structured value, the 
components of which can be repeated but in which order is important, 
each structured value component shall be allowed to be represented 
either a single value or as an rdf:List value. If there is no official 
name defined for a particular structured value subcomponent, one shall 
be created that is as close as possible to the name used in the 
specification in referring to that component, using the 
example:mixedCase format. e.g. The subcomponent "Additional Name" of the 
vCard N type would appear as a vcard:additionalName property of the 
vcard:N class which would appear as a value of the vcard:n property. The 
value of the vcard:additionalName property could be single literal 
value; a blank node with its rdf:value set to the literal value (if, for 
instance, the directory:language needed to be specified for the value), 
or an rdf:List of blank nodes as just described (using a rdf:parseType 
of Collection in RDF+XML syntax, for example).

So that means I could have a plain literal:

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

...a complex string value:

<card:N>
  <card:firstName>
    <rdf:Description directory:language="en" dc:description="My first 
Name" rdf:value="George"/>
  </card:firstName>
</card:N>

...or a list of first names:

<card:N>
  <card:firstName rdf:parseType="Collection">
    <rdf:Description rdf:value="George"/>
    <rdf:Description rdf:value="Ahmed"/>
  </card:firstName>
</card:N>

You can see that this is very flexible, but it's not a free-for-all. Any 
processor would be able to understand the name value just by using the 
rules. It would still cover most of what vCard provides, and the common 
case would collapse into what we expect normally: 
<card:N><card:firstName>George</card:firstName></card:N>

> Since many names do not map
> easily, as you have rightfully pointed out, to the "components" of the
> name, the way to sort names that have multiple components each with
> their own sorting rules is simply to specify a "v:sort-string"
>
> So, the current vcard proposal would have precisely what you said:
>
> <v:sort-string>Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."</v:sort-string>?
>   

I think you missed my point. I didn't provide that for a sorting name. I 
provided that as an indication of what we could do for storing the 
components if we force a simple storage structure---we might as well 
have literal vCard data within the RDF instance, which is what I put 
above. That's straight out of RFC 2426. Sorting is another issue 
altogether, one which seems straightforward with a sort string as you 
mentioned, and one about which I'm not particularly concerned.

So in summary, here's what I'm saying: if we set as a goal of this 
endeavor to create an RDF ontology that simply but reasonably completely 
maps to data in the vCard specification, we need to have a format that 
is not so restrictive that it discards a bunch of vCard data but not so 
lenient that processors will not be able in the absence of rules outside 
the specification to understand the data. 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

>
>
>
> Kjetil Kjernsmo wrote:
>   
>> On Monday 26 March 2007 21:16, Garret Wilson wrote:
>>   
>>     
>>> On the other hand, though, the entire ontology has been so restricted
>>> as to become hardly usable in an international environment. A case in
>>> point is the v:Name class, which only allows a single instance of
>>> each name component. The names-in-FOAF discussion has already pointed
>>> to the Dublin Core analysis (
>>> http://dublincore.org/documents/name-representation/ ) of the rich
>>> variety of naming conventions around the world. The current
>>> http://www.w3.org/2006/vcard/ns proposal could hardly handle the name
>>> of His Majesty King Abdullah II bin Al Hussein of Jordan. Sure, I
>>> know that we could take a couple of those name components, separate
>>> them with commas, and stick them into one of the existing v:Name
>>> components, but if we're going to do that why don't we do away with
>>> the v:Name class altogether and stick a literal vCard string into one
>>> component, like this:
>>> <v:n>Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."</v:n>?
>>>     
>>>       
>> Actually, that's the topic that we devoted most of the time on an ad hoc 
>> face to face meeting in Boston in January with TimBL, Harry Halpin and 
>> myself present, as well as several others on IRC and phone. 
>>
>> Tim himself has a whole array of titles, and we discussed examples like 
>> the one you had. We resolved that Harry would produce an update soon, 
>> but I guess he has been swamped in other work. 
>>
>> But at least, you know that it is an active topic. 
>>
>> Best,
>>
>> Kjetil
>>   
>>     
>
>
>

Received on Tuesday, 27 March 2007 15:18:39 UTC