Re: New vCard Ontology draft

On 3 May 2013 09:22, "Dave Reynolds" <dave.e.reynolds@gmail.com> wrote:
>
> On 02/05/13 15:56, Ivan Herman wrote:
>>
>> The Semantic Web Interest Group has published a new draft for the
vCard-in-RDF Ontology[1], edited by Renato Iannella and James McKinney. The
new draft updates the previous version[2] by aligning it with the latest
IETF vCard specification, ie, RFC6350[3].
>>
>> This is a draft; comments on the draft should be sent to the SWIG
mailing list. The goal is to publish an Interest Group Note once there is a
consensus in the community.
>
>
> Thanks for this. Some comments based on a quick skim rather than an in
depth review.
>
> 1. As noted in the Issue in section 1, this new vocabulary needs to be in
a new namespace. This will be inconvenient but I see no other choice given
the new design. Specifically:
> (a) Many of the properties that look similar between this specification
and the previous one have changed their name (adr, street-address, fn etc).
So I assume that the intent is that the old names would not be permitted
under this new specification.
> (b) There has been a substantial shift in semantics from talking about
properties of VCards (information records) to properties of entities (e.g.
individuals).

Interesting. Is that a reflection of changes in vCard, or in thinking about
its Rdfization? That should make mappings easier.

Dan

> 2. The relationship between "Relation" and "Direct" properties needs
further explanation. Do you intend that there be an entailment
relationship? For example, should the Relation form:
>
>     :me vcard:hasFormattedName [
>              a vcard:FormattedName;
>              vcard:formattedName "Dave";
>     ] .
>
> entail the direct form:
>
>     :me vcard:formattedName "Dave" .
>
> I think it should, in which case you need to express this (e.g. using owl
property chain axioms or closure rules). If you don't want such entailments
to hold then you need to state that and explain when authors should use
relational form instead of direct form and how clients are supposed to
handle the differences between the two forms.
>
> 3. The domain/ranges of the Relation and Direct properties are confusing,
if not actually inconsistent. As I understand it you want to be able to use
the Direct properties like vcard:formattedName on the entity or on the
n-ary relation (as in the above example).
>
> Yet the domain of the Direct properties is declared as being the class of
the n-ary relation. For example, vcard:formattedName has domain
vcard:FormattedName but is shown in the table 2.3 as a Direct property and
in your example in section 3 is used directly on a vcard:Individual.
>
> So this means that <http://example.com/me/corky> in your example is both
a vcard:Individual and a vcard:FormattedName. I don't think you have any
disjointness axioms which rule that out but I suspect it is not what you
mean.
>
> Suggest that you either have different properties for the Direct
relationship and the component of the n-ary relationship, or you leave the
domains of these two-mode properties as open. I might suggest having a
union but that would mean defining some new classes as well.
>
> 4. The notation used in the tables in section 2 is confusing. You are
using dp: op: and class: as if they were (undefined) namespace prefixes.
Whereas it appears they are all the same namespace and the prefixes are
used to indicate type. Recommend just using a single prefix and not bother
with the type distinction in those tables.
>
> 5. The text in the vocabulary reference is a little confusing in its use
of labels instead of localnames to refer to the terms. This confusion might
be reduced if the labelling were more consistent. For example, it took me a
while to realize that the label "has format name" refers to
vcard:formattedName whereas "has formatted name" refers to
vcard:hasFormattedName. Suggest that use of things like "has" should be
consistent between the label and the localname. Similarly the use of
abbreviations in the labels is inconsistent (e.g. "Org" for
"vcard:Organization").
>
> 6. It would be helpful to have a section discussing the relationship
between this and existing vocabularies such as foaf and ORG.
>
> Dave
>
>
>