As raised during the SDWIG telco last week, I would like to caution against using the Basic Geo vocabulary in DCAT2 for expressing location. As Dan Brickley pointed out to us, it was designed as an exercise and has not had careful review. In the SDW roadmap we describe this vocabulary as discontinued.
On the other hand, it is still a widely used property for describing location on the web.
Perhaps a note of caution in the DCAT2 document would be wise.
In the SDW roadmap we describe this vocabulary as discontinued.
Thanks @lvdbrink I had not realised Basic Geo was so far down the stack now.
Is a warning note enough?
Is a warning note enough?
That would be the minimal solution I guess. Since it is used a lot, I'm hesitant to recommend not to use it at all. On the other hand, DCAT2 is a standard, so should it reference such an ad hoc created vocabulary?
Yes, that is a good point. In the current draft w3cgeo:lat, w3cgeo:long and w3geo:alt are 'recommended for use' on individuals from the class dct:Location. I'm now thinking that these probably should not appear in the normative clause at all. We might leave the example but with a more prominent warning note (OWA etc). What do you think @andrea-perego ?
I'm also not sure. One reason to keep it is that, in DCAT2, w3cgeo is the only option to specify point coordinates separately, which may be relevant for some use cases - the other properties use WKT as a recommended encoding.
I'm also unsure about recommending against the use of w3cgeo. It is indeed used a lot - LOV reports 48 incoming links:
https://lov.linkeddata.es/dataset/lov/vocabs/geo
I remember when @danbri was explaining how w3cgeo was developed. It is true that it is no longer maintained, and it didn't have wide review, but the fact that is being used so much, and for such a long time, to me means that it is fit for purpose (at least for the vocabularies re-using it). Also, schema.org uses an equivalent representation for points, and since schema.org is under a continuous review, I wonder whether the option of deprecating those properties was discussed and, in such a case, why the decision was not to deprecate them.
including both dcat:centroid and w3cgeo:lat, w3cgeo:long as 'SHOULD be used' works against interoperability- two ways to do the same thing. The WKT point representation allows encoding the same information as w3cgeo lat,long,alt, I'd prefer to see the recommendation for dcat:centroid, to avoid having multiple ways to encode the same information.
@lvdbrink , @smrgeoinfo , this issue was discussed during the last call of the DCAT subgroup, and the decision was to remove w3cgeo properties from DCAT - see https://www.w3.org/2019/07/10-dxwgdcat-minutes#x05
This revision has been implemented via PR https://github.com/w3c/dxwg/pull/988
Thanks a lot for your feedback.
Most helpful comment
I'm also not sure. One reason to keep it is that, in DCAT2, w3cgeo is the only option to specify point coordinates separately, which may be relevant for some use cases - the other properties use WKT as a recommended encoding.
I'm also unsure about recommending against the use of w3cgeo. It is indeed used a lot - LOV reports 48 incoming links:
https://lov.linkeddata.es/dataset/lov/vocabs/geo
I remember when @danbri was explaining how w3cgeo was developed. It is true that it is no longer maintained, and it didn't have wide review, but the fact that is being used so much, and for such a long time, to me means that it is fit for purpose (at least for the vocabularies re-using it). Also, schema.org uses an equivalent representation for points, and since schema.org is under a continuous review, I wonder whether the option of deprecating those properties was discussed and, in such a case, why the decision was not to deprecate them.