Re: update on vCard edits and The Compromise

Bruce D'Arcus wrote:
>
> Harry Halpin wrote:
>> While the OWL hack is workable, again, the goal of this is to keep vCard
>> as simple as possible. The only real bug in our goal is that some of the
>> data in VCard, such as names, is by nature ordered. While collections
>> are closed, I concur with Benjamin that we could use a container ) such
>> as rdf:Seq as used in the older VCard/RDF Spec [1]. It's currently my
>> preference. although sequences are not, per se, closed like a
>> collection, but it's close enough for me
>>
>> Here's an example from [1]:
>>
>>       <vCard:TITLE>              <rdf:seq>
>>             <rdf:li> Principal Research Scientist </rdf:li>
>>             <rdf:li> Visiting Professor </rdf:li>
>>          </rdf:seq>
>>      </vCard:TITLE>
>>
>> So I think we could s/vcard:additionalNames/vCard:TITLE in this
>> example and we'd have a pretty good solution. Garret - do you agree?
>> I'd like to push out your changes to the spec right now, but want
>> some agreement on this beforehand.
>
> I'm now totally lost.
>
> Everyone I have talked to has discouraged use of rdf:Seq. AFAIK, you
> cannot really query it reliably with SPARQL either, though am not sure
> of that.
Is that true? Oh dear. Anyone have more info?
> But also the original update simplified things by removing order from
> the modeling so in part to make it easy to convert between it and hCard.
That is a good use-case.
> So what are we now proposing, for what use case?

> It's not clear to me how allowing order in additional names is
> actually helping us, for example. Are we also proposing it be allowed
> elsewhere??
The two options are to:

1) Have all names, including "additional-name" be unordered, and then
have a sort-string that orders them. That was Norm's design decision.

2) The compromise with Garrett is to allow "additional-names" to be an
ordered list/sequence of some kind, as well as "honorable-prefixes" and
"honorable-suffixes".

Therefore, we have 3 places with names can be ordered. This is important
for Garrett as he is interested in converting vCard to vCard->RDF, and
preserving order in a machine-processable manner, which is difficult
with reliance on just "sort-string"

I would suggest that the compromise is a proper-superset of Norm's
proposal, since we should not force the use of sequences/lists where not
needed, as in:

    <vcard:honorable-prefixes>             
         <rdf:seq>
            <rdf:li>Mr.</rdf:li>
         </rdf:seq>
     </vCard:honorable-prefixes>

should just be:

    <vcard:honorable-prefixes>             
            Mr.
     </vCard:honorable-prefixes>

but would allow one to mark ordering where important

    <vcard:honorable-prefixes>             
         <rdf:seq>
            <rdf:li>Sir</rdf:li>
            <rdf:li>Mr.</rdf:li>
         </rdf:seq>
     </vCard:honorable-prefixes>

Does that make sense? I imagine hCard transforms will *not use* any
Sequence or Lists, but they will not be banned by the spec, instead the
spec will say precisely where they are allowed. This makes writing
generic vCard/RDF processors (as Garrett I think is doing) easier,
unlike the original vCard specification which allows Bags/Alt/Sequences
to be basically anywhere.

> Bruce
>
>


-- 
  -harry

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

Received on Thursday, 26 July 2007 13:39:46 UTC