vCard

[Gibson, A.P.]

Hello pedants,

I was just trying to do something with the vCard URI:

<http://www.w3.org/2001/vcard-rdf/3.0#>

...and was having a few 'issues'.

With some help from Rinke, this document hasn't got the propert rdf:RDF elements, and so wont even run against the W3C validator. When you fix that and do run it against the validator, there are all sorts of syntax problems reported.

This would seem to be the sort of thing this list is about ;-) I'm not sure what the status of vCard is and maybe these issues are already known, but it does seem to be used, is in the W3 namespace and is in the SPARQL documentation as an example.

Anyone care to try investigating/reporting this in more detail?

Cheers,
Andrew

Dr Andrew Gibson
Universiteit van Amsterdam

[Hogan, Aidan]

Hi Renato,

Below you can find an email from Andrew Gibson regarding some parsing errors with the RDF document retrievable from [1]. I found your contact details from [2], and hope you could solve these issues. If you no longer maintain the vCard schema, could you point us towards/forward these email to a current maintainer? I understand that the specification is quite old.

After further investigation, it seems that there are three syntactic errors in that document. The document does not validate according to the W3C RDF/XML validator [3]. The following are suggestions to solve these:
* Change opening and closing '<rdf>' tags to '<rdf:RDF>'
* Change namespace declaration from 'xmlns:vcard=' to 'xmlns='; i.e., declare the vCard namespace as the default to correspond with usage in the data
* There are duplicate rdf:IDs 'home' 'work' 'pref'; rdf:IDs must be unique for a document and so, for these terms you should use, e.g., 'rdf:about="#home'
* Related to the above, the document should use a base URI: add 'xml:base="http://www.w3.org/2001/vcard-rdf/3.0"' with the namepsace declarations

Aside from syntactic issues, there are some schema/ontological level errors in the data. There is large confusion in the interrelationship between classes and properties. For example, the property 'Family' is defined as a sub*class* of NPROPERTIES. If you wish to fix such issues, and need some more detailed comments, please don't hesitate to reply.

Cheers,
Aidan Hogan

http://pedantic-web.org/

[1] http://www.w3.org/2001/vcard-rdf/3.0#
[2] http://www.w3.org/TR/vcard-rdf
[3] http://www.w3.org/RDF/Validator/ARPServlet

[Renato Iannella]

Hi all - thanks for the comments...I did try and make some changes to
the rdf schema a number of years ago, but could not, as I was not a
member of W3C anymore....

But, some bigger changes have now occurred and we are about to release
an update to the original W3C NOTE.

Please see the draft here:
http://spin.nicta.org.au/vcardrdf/vcard-rdf-20090924.html

And send my any comments....does this address your concerns fully?

Cheers

Renato Iannella
http://renato.iannella.it

[Renato Iannella]

Here is a small update:

http://spin.nicta.org.au/vcardrdf/vcard-rdf-20091029.html

Cheers... Renato Iannella
NICTA

[Richard Cyganiak]

Renato,

On 28 Oct 2009, at 20:27, Renato Iannella wrote:
> But, some bigger changes have now occurred and we are about to
> release an update to the original W3C NOTE.
>
> Please see the draft here:
> http://spin.nicta.org.au/vcardrdf/vcard-rdf-20090924.html
>
> And send my any comments....does this address your concerns fully?

The updated version is a huge improvement over the original, so it's
great to see it progressing.

But it doesn't address the core of the original question. Andrew and
Aidan pointed out the problems present in the RDF that's resolvable
from the original 2001 namespace:

<http://www.w3.org/2001/vcard-rdf/3.0#>

The new draft uses a different namespace (from 2006):

<http://www.w3.org/2006/vcard/ns#>

What will happen to the RDF document available at the original 2001
URI when the current draft progresses? Will it be replaced with the
2006 version? Will the syntactic issues that Aidan pointed out be
fixed? Or are such things out of scope of your current activity?

The problem is that there's RDF data out there that uses the 2001
namespace, and the 2001 namespace is used in examples in the SPARQL
spec, and leaving it in its current broken state is a problem.

(I'm CC'ing Harry, who also might be able to shed light on any W3C
process issues.)

Richard

[Harry Halpin]

On Sat, Oct 31, 2009 at 7:59 PM, Richard Cyganiak <ric...@cyganiak.de> wrote:
> Renato,
>
> On 28 Oct 2009, at 20:27, Renato Iannella wrote:
>>
>> But, some bigger changes have now occurred and we are about to release an
>> update to the original W3C NOTE.
>>
>> Please see the draft here:
>> http://spin.nicta.org.au/vcardrdf/vcard-rdf-20090924.html
>>
>> And send my any comments....does this address your concerns fully?
>
> The updated version is a huge improvement over the original, so it's great
> to see it progressing.
>
> But it doesn't address the core of the original question. Andrew and Aidan
> pointed out the problems present in the RDF that's resolvable from the
> original 2001 namespace:
>
> <http://www.w3.org/2001/vcard-rdf/3.0#>
>
> The new draft uses a different namespace (from 2006):
>
> <http://www.w3.org/2006/vcard/ns#>
>
> What will happen to the RDF document available at the original 2001 URI when
> the current draft progresses? Will it be replaced with the 2006 version?
> Will the syntactic issues that Aidan pointed out be fixed? Or are such
> things out of scope of your current activity?

I have to proof-read the draft (will try to do later this week, sorry,
a bit overwhelmed right now with a paper deadline).

Re W3C Process, we will update the spec so that the namespace URIs
redirect to each other, depending on the content type. Then the
previous spec will be archived under "previous version" so it will
always be accessible. Is this acceptable?

[Richard Cyganiak]

Hi Harry,

On 1 Nov 2009, at 15:21, Harry Halpin wrote:
> I have to proof-read the draft (will try to do later this week, sorry,
> a bit overwhelmed right now with a paper deadline).
>
> Re W3C Process, we will update the spec so that the namespace URIs
> redirect to each other, depending on the content type. Then the
> previous spec will be archived under "previous version" so it will
> always be accessible. Is this acceptable?

Just to clarify: Your plan is to have both of the following namespaces

<http://www.w3.org/2001/vcard-rdf/3.0#>
<http://www.w3.org/2006/vcard/ns#>

serve the same RDFS, namely an updated version of what's currently
available at the second (2006) namespace?

I would agree with that course of action.

Richard

[Rinke Hoekstra]

Hi,

Wouldn't it make more sense to just not introduce the 2006 namespace
at all?
This is the approach that was taken by the OWL WG for OWL 2, and by
the people working on SKOS as well (they even did a rollback to the
old namespace).

Although it does mean that we'll be stuck with an old datestamped and
versioned namespace URI, it will prevent any confusion that the two
separate but equivalent namespaces would cause. Another advantage is
that no examples need to be changed anywhere, and existing systems
that may depend on the 2001 namespace will continue to run on RDF
stuff that uses the new and improved VCard RDF specification. If the
new spec is not backwards compatible with the old one, having two
separate namespaces doesn't solve this either (since both namespace
URIs will redirect to the new spec anyway).

So, IMHO, dates and version numbers in namespace URIs are bad idea.

Cheers,

Rinke

---
Dr Rinke Hoekstra

AI Department | Leibniz Center for Law
Faculty of Sciences | Faculty of Law
Vrije Universiteit | Universiteit van Amsterdam
De Boelelaan 1081a | Kloveniersburgwal 48
1081 HV Amsterdam | 1012 CX Amsterdam
+31-(0)20-5987752 | +31-(0)20-5253499
hoek...@few.vu.nl | hoek...@uva.nl

Homepage: http://www.few.vu.nl/~hoekstra

[Richard Cyganiak]

On 2 Nov 2009, at 12:19, Rinke Hoekstra wrote:
> Wouldn't it make more sense to just not introduce the 2006 namespace
> at all?

I agree, but it's too late, the 2006 namespace has been around for a
while and is deployed.

> This is the approach that was taken by the OWL WG for OWL 2, and by
> the people working on SKOS as well (they even did a rollback to the
> old namespace).

AFAIK the situation with vCard was a little bit different from the OWL/
SKOS situations. There were two independent efforts to translate vCard
into RDF. Both are quite incompatible.

AFAICT, the 2001 version predates “modern” RDF and actually uses the
old, 1999-style RDF/XML syntax. That's what causes the breakage, and
why we want the old version gone.

> Although it does mean that we'll be stuck with an old datestamped
> and versioned namespace URI, it will prevent any confusion that the
> two separate but equivalent namespaces would cause. Another
> advantage is that no examples need to be changed anywhere, and
> existing systems that may depend on the 2001 namespace will continue
> to run on RDF stuff that uses the new and improved VCard RDF
> specification. If the new spec is not backwards compatible with the
> old one, having two separate namespaces doesn't solve this either
> (since both namespace URIs will redirect to the new spec anyway).
>
> So, IMHO, dates and version numbers in namespace URIs are bad idea.

+1.

Richard

[Alex Tucker]

> So, IMHO, dates and version numbers in namespace URIs are bad idea.

Doesn't it depend on whether you ever expect to make backward
incompatible changes?

Alex.

[Rinke Hoekstra]

Well, I guess it means that if you make changes that *are* backward
compatible, you shouldn't change the version number. So, in that case,
a version number (or date) is pretty useless.

The W3C has a policy of changing the name of a language if changes are
no longer backward compatible (CSS -> XSLT, HTML -> XHTML). See
Sandro's message on RDF 2 [1]

Ah well... there's no rule that says "don't put version numbers or
dates in your namespace", so I can hardly be pedantic about it ;)

Cheers,

Rinke

[1] http://decentralyze.com/2009/10/30/rdf-2-wishlist/

[Hogan, Aidan]

Hi Renato,

Thanks for the response! Indeed, greatly improved. Also nice to see
RDF-esque capitalisation employed!

From a quick scan, I've noticed that the example in [1, Section 4] is
not valid RDF/XML (missing '"' at the end of namespace declaration,
'v:rle' ending tag, etc.). Also, in the examples you use plain-literal
values for 'bday' instead of asserting the value to be an 'xsd:date' as
specified by the property's range.

Also, there seems to be some confusion about using 'wgs84' properties
for lat and long, and your own properties defined in the namespace. I
would, of course, strongly encourage the former to reflect consensus in
the community.

On a modelling level, you define maxCardinality restrictions for some of
your properties on some of your classes. You seem to adopt them as
"integrity constraints" to state that a member of a class should only
have one value for the given property; however, standard interpretation
of these definitions will not be as a constraint, but instead will infer
equality between multiple such values (where they exist). Worth keeping
in mind perhaps! Do you expect applications to adopt such restrictions
in terms of "integrity constraints" using here the UNA, and if not, why
maintain such restrictions? What if I want to define a name/address in
two languages? In my opinion, such restrictions are impractical and add
unnecessary complication.

Which brings me onto my last point: the range of the 'rev' property.
Again, you seem to have your integrity-constraint hat on again, stating
that a 'rev' value must either be an xsd:date or xsd:dateTime. However,
no meaningful inference can take place here, and I would much prefer
using just one or the other.

Cheers,
Aidan

[1] http://spin.nicta.org.au/vcardrdf/vcard-rdf-20091029.html

[Renato Iannella]

On 4 Nov 2009, at 02:07, Hogan, Aidan wrote:

> Also, there seems to be some confusion about using 'wgs84' properties
> for lat and long, and your own properties defined in the namespace. I
> would, of course, strongly encourage the former to reflect consensus
> in
> the community.

Hi Aidan - can you be a bit more specific for the above?

Thanks for your other comments - I will discuss with the other Authors
and get back to you...

Cheers... Renato Iannella
NICTA

[Hogan, Aidan]

Hey Renato,

> > Also, there seems to be some confusion about using 'wgs84'
properties
> > for lat and long, and your own properties defined in the namespace.
I
> > would, of course, strongly encourage the former to reflect consensus
> > in the community.
>
> Hi Aidan - can you be a bit more specific for the above?

My apologies. This is my confusion, not yours. I was looking
simultaneously at the RDF/XML doc from [1] and the spec at [2]. I've
just realised that [1] is from 2006, and [2] is the updated doc from
2009. [1] defines new latitude/longitude properties, whereas [2] uses
g:lat and g:long (I was saying that I prefer the latter, not realising
that they were different versions). Assuming the doc at [1] will be
updated with a new RDF/XML spec, everything is fine... If you want to
send on a link to an updated RDF/XML ontology, whenever it becomes
available, we'd be more than happy to have a look.

> Thanks for your other comments - I will discuss with the other Authors
> and get back to you...

No problem! Part of the job description. Thanks for responding!

Cheers
Aidan

[1] http://www.w3.org/2006/vcard/ns
[2] http://spin.nicta.org.au/vcardrdf/vcard-rdf-20091029.html

[Renato Iannella]

On 6 Nov 2009, at 00:50, Hogan, Aidan wrote:

> My apologies. This is my confusion, not yours. I was looking
> simultaneously at the RDF/XML doc from [1] and the spec at [2]. I've
> just realised that [1] is from 2006, and [2] is the updated doc from
> 2009. [1] defines new latitude/longitude properties, whereas [2] uses
> g:lat and g:long (I was saying that I prefer the latter, not realising
> that they were different versions). Assuming the doc at [1] will be
> updated with a new RDF/XML spec, everything is fine... If you want to
> send on a link to an updated RDF/XML ontology, whenever it becomes
> available, we'd be more than happy to have a look.

Aidan - a bit our problem to as we were not keeping the two documents
in synch...

Actually, for the long/lat, [2] is the preferred approach - since
vCard itself does not define long/lat properties (only Geo) - we felt
it better to reuse an existing ontology (a bit of it) to express these
values.

In Appendix B we note this and recommend the new approach but
recognise the existing data out there...

Renato

[2] http://spin.nicta.org.au/vcardrdf/vcard-rdf-20091029.html

[Hogan, Aidan]

Hey Renato,

I gave a quick scan and have some initial comments about the
specification (I'm talking purely from the perspective of a machine for
the moment, and pointing out errors ;) ).

For both of the properties vcard:bday and vcard:rev, you seem to want to
say that values can be either xsd:date or xsd:dateTime. This is very
different from doubly defining the range as below:

<owl:DatatypeProperty rdf:about="&vcard;bday">
...
<rdfs:range rdf:resource="&xsd;date"/>
<rdfs:range rdf:resource="&xsd;dateTime"/>
...
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:about="&vcard;rev">
...
<rdfs:range rdf:resource="&xsd;date"/>
<rdfs:range rdf:resource="&xsd;dateTime"/>
...
</owl:DatatypeProperty>

What you are in effect saying here is that any value for vcard:bday is
*both* an xsd:date and xsd:dateTime -- not that it it's one or the
other. (It is possible to do the latter using a unionOf class, but I
don't think you should... I think you should choose one datatype).
However, according to the XSD documentation, xsd:date and xsd:dateTime
are disjoint; you cannot have a value which is a member of both
datatypes (which is impossible anyways: a literal cannot be a lexically
valid xsd:date and xsd:dateTime at the same time).

Solution: well first of all, I think by bday, you actually mean dob
(date of birth), and so xsd:date is perfectly valid (remove the
xsd:dateTime range, which is far too specific for this purpose). If you
do actually mean birthday, you can model it using the xsd:gMonthDay
datatype. For revision, use xsd:dateTime (or even better:
xsd:dateTimeStamp [1]): if people don't want to specify a time, they can
simply use 2002-10-10T00:00:00Z for example (set the time to zero).

Also, there are some issues with your modelling of classes. You state
that Address is disjointWith Email, Label and Tel (and thus,
vice-versa):

<owl:Class rdf:about="&vcard;Address">
...
<owl:disjointWith rdf:resource="&vcard;Email"/>
<owl:disjointWith rdf:resource="&vcard;Label"/>
<owl:disjointWith rdf:resource="&vcard;Tel"/>
...
</owl:Class>

However, e.g., you define Home as a subClassOf Address, Label and Tel.
<owl:Class rdf:about="&vcard;Home">
...
<rdfs:subClassOf rdf:resource="&vcard;Address"/>
<rdfs:subClassOf rdf:resource="&vcard;Label"/>
<rdfs:subClassOf rdf:resource="&vcard;Tel"/>
...
</owl:Class>

Now, every member of Home is a member of Address, Label and Tel and
Address is disjointWith Label and Tel. Hence, Home can only be an empty
class: if anything is made a member of Home, the data is inconsistent.

The same is true for Parcel, Postal, Pref and Work. For each class, I
guess you'll have to decide what the true super-class is.

I have other comments, but I'll leave them for later. These are all of
the errors I noticed on a first scan anyways ;).

Cheers,
Aidan

[1] http://www.w3.org/TR/xmlschema11-2/#dateTimeStamp

> -----Original Message-----
> From: Renato Iannella [mailto:ren...@nicta.com.au]
> Sent: 19 November 2009 01:04
> To: Hogan, Aidan
> Cc: a.p.g...@uva.nl; pedant...@googlegroups.com
> Subject: Re: [pedantic-web] vCard
>

> Attached is the proposed final schema...
>
> Cheers... Renato Iannella
> NICTA

[Rinke Hoekstra]

Hi Aidan,

On 19 nov 2009, at 16:37, Hogan, Aidan wrote:

> However, e.g., you define Home as a subClassOf Address, Label and Tel.
> <owl:Class rdf:about="&vcard;Home">
> ...
> <rdfs:subClassOf rdf:resource="&vcard;Address"/>
> <rdfs:subClassOf rdf:resource="&vcard;Label"/>
> <rdfs:subClassOf rdf:resource="&vcard;Tel"/>
> ...
> </owl:Class>
>
> Now, every member of Home is a member of Address, Label and Tel and
> Address is disjointWith Label and Tel. Hence, Home can only be an empty
> class: if anything is made a member of Home, the data is inconsistent.

This is not true. Contrary to the domain/range example, multiple rdfs:subClassOf relations should be interpreted as a union. So, House is the union of three disjoint classes, which makes perfect sense as long as no individual of type House is also a type of more than one of the disjoint superclasses.

Cheers,

Rinke

---
Dr Rinke Hoekstra

AI Department | Leibniz Center for Law
Faculty of Sciences | Faculty of Law
Vrije Universiteit | Universiteit van Amsterdam
De Boelelaan 1081a | Kloveniersburgwal 48
1081 HV Amsterdam | 1012 CX Amsterdam

+31-(0)20-5987752 | +31-(0)20-5253497

[Rinke Hoekstra]

Please ignore my message, and forget about it as soon as possible.

-Rinke (being overly pedantic again)

[Hogan, Aidan]

> Please ignore my message, and forget about it as soon as possible.
>
> -Rinke (being overly pedantic again)

Hey Rinke,

And I had written such a nice counter-reply. I guess we'll never get to
read it ;).

[Rinke Hoekstra]

I wish today was Friday... then at least I'd have an excuse.

-Rinke

[Renato Iannella]

Hi Aidan - thanks for your comments....

For bday and rev, RFC2426 states that both date and datetime are valid types.
So I think we need to make that a union.

For the "modelling of classes" issue - I will look deeper into it - thanks!

Cheers... Renato Iannella
NICTA