Re: New vCard Ontology draft

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

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

Received on Friday, 3 May 2013 08:21:40 UTC