Re: yet another RDF vCard

Harry,

Harry Halpin wrote:
>     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.
>   

Hmmm... I included it as text in my first message---I had assumed that 
HTML attachments weren't allowed. I'm attaching it to this message, 
though. Note that this isn't the specification---this is a draft of an 
article in which I was outlining the logic to be used in creating a 
specification. A specification (or most of one) is derivable from the 
rules therein, though. I also include a few examples---most importantly 
of the name issue---of what would be in the specification, based upon 
those rules.

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

No, no. I prefer *both* v:n as a property and v:Name (or card:N) as a 
class. That's the way it is in http://www.w3.org/2006/vcard/ns , and the 
way it is in my proposal as well.

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

*That* was my point. I was trying to state that, if you have a name that 
doesn't fit within this restricted cardinality, you have to fit them in 
somehow, perhaps with some sub-syntax. Once you do that, you might as 
well use vCard syntax for the whole field---which makes RDF irrelevant 
to some extent.

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

That was my point. Maybe I stated it too elaborately... :)

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

You have no arguments from me there---that was the way I proposed it as 
well. Properties and classes are two separate beasts. v:n indicates that 
something has a relationship of a name. v:Name indicates that the thing 
is a name type. So you might have properties v:n and v:mothersName, both 
of which have a range of v:Name. I would only propose that the class be 
named v:N (and v:Adr and so forth) out of complete consistency with the 
vCard specification---otherwise, we'll have to make arbitrary decisions 
about when to keep the vCard name and when to give it a more 
aesthetically pleasing name. I'd prefer to have a set of rules for 
creating the ontology---something that could theoretically be done by a 
machine reading RFC 2426.

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

Thanks for the support. If I don't hear any serious objections, how 
about I create a clearer and more complete set of rules? (The current 
rules were jotted down at the end of the day after I wrote the article, 
so they can definitely be improved.) I was going to do this anyway, but 
if people here like the idea, I'll write them with the purpose of your 
using them in your specification, rather than for me to stick in a 
separate specification that I write when I get the time...

Here are what will be my guiding principles, off the top of my head:

    * The RDF ontology will capture virtually all information that will
      be found in virtually all vCards. (Whatever that means---I think
      the negative will be easy to see, though.)
    * The specification will be clear enough so that if Processor A
      converts vCard A to RDF instance A, Processor B can convert RDF
      instance A to vCard B just by reading the specification, and vCard
      B will be equivalent to vCard A.
    * The specification, as much as possible, will be consistent with
      RFC to the extent that the specification can be machine-produced
      by parsing RDF 2426 and following a set of rules.
    * The RDF ontology will take advantage of the relationship among
      Directory, vCard, and iCalendar so that, as much as possible, the
      same conversion rules (both to produce the specification and to
      convert to RDF) will be applicable to all three.


On that last point, I would prefer three specifications, or at least 
specification subsections, dealing with Directory, vCard, and iCalendar. 
For example, the "language" param and some valuetypes are defined in 
Directory, not vCard, and are applicable to both vCard and iCalendar. 
These should not be part of a vCard ontology, but part of a general 
Directory ontology. I would prefer three separate namespaces, as I 
indicate in the draft article. But read the article and you'll get an 
idea of where I'm coming from.


>>   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 :)
>   

Not so much. Just a couple of methods would do most of the work. For 
example:

/**Retrieves vCard text from a given RDF object.
If the object is an {@link RDFLiteral}, the lexical form of the literal 
will be returned.
If the object is an {@link RDFResource}, the {@link RDFLiteral} 
<code>rdf:value</code> of each resource, if present, will be used for 
the text,
and any <code>directory:language</code> property of resource will be 
used to determine the language of the text.
In either case, a language designation by <code>xml:lang</code> for the 
actual literal text will take precedence, as this value is specified 
most closely to the text.
@param rdfObject The object that is supposed to represent text.
@return An object representing the text and any language specification, 
or <code>null</code> if the object does not represent text.
@exception NullPointerException if the given RDF object is 
<code>null</code>.
*/
public static LocaleText getText(final RDFObject rdfObject);

/**Retrieves an array of vCard text from a given RDF object in a context 
that expects one or more text values to be present.
If the object is an {@link RDFListResource}, an array will be created 
from the result of {@link #getText(RDFObject)} for each list element;
<code>null</code> text values will be excluded from the list.
If the object is an {@link RDFLiteral} or {@link RDFResource}, an array 
with a single element will be returned containing the result of {@link 
#getText(RDFObject)}.
@param rdfObject The object that is supposed to represent text or a list 
of text.
@return An array of objects representing the text and any language 
specification.
@exception NullPointerException if the given RDF object is 
<code>null</code>.
*/
public static LocaleText[] getTexts(final RDFObject rdfObject);

Garret