Re: [dxwg] vCard and FOAF? (#955)

My view:

Firstly, from a more theoretical, modelling perspective:

From my recollection of the discussions in the Government Linked Data WG back when DCAT 2014 was developed, we understood that there was a difference between the semantics of `foaf:Person` and `vcard:Individual`. Whereas members of the class `foaf:Person` are people, like Dan or Renato or Makx, members of the class `vcard:Individual` are bits of information about people, like electronic business cards. Compare the definitions: `foaf:Person=”A Person”` ( versus `vcard:Individual=”An object representing a single person or entity”` ( This may of course be considered a very pedantic reading of the definitions, but I think this was the reason a distinction was made in DCAT 2014, in addition to the fact that the definition in VCARD seemed to fit very well with what `dcat:contactPoint` was supposed to link to: contact information rather than a person or organisation.

Secondly, from a process perspective:

What is our policy to add more standards and options to the spec? If other people came along proposing that their standard is also included – and I note that for example the term Person is defined in 2242 vocabularies according to – would we add those too? I understand from Renato’s example that the ODRL people thought that, FOAF and VCARD were all ‘well known’, but why not add, for example, `org:Organization` – the list would become very long if you really wanted to go that way. Where’s the limit?

Thirdly, from a practical perspective:

In my mind, allowing more choices for metadata creators may not be always beneficial. Adding options to use other standards may be confusing. To me, adding more choices just for the sake of it is not what we should be trying to do. The current definitions of the properties that are supposed to point to persons, organisations etc. seem to me to be OK, and the one that is supposed to point to contact information is OK too, and if there is a need to explain the difference we should add an explanation. 
I do understand that adding choices might make life easier for metadata creators – they can just use what they like best – but it makes life more difficult for consumers of that metadata. At least, consuming applications would need to have some branching logic depending on what they get (and probably will happily ignore what they don’t expect), while of course big AI-aided search engines would be able to figure things out in a more sophisticated way. Aren’t we shifting the burden to smaller linked data applications this way?

Finally, the effect on interoperability could be serious – existing applications, in particular consuming ones, that are based on DCAT 2014 would have to be rewritten to include the additional options. 

My opinion is and has always been that we should not try to add choices and relax ranges if it is not absolutely necessary. 

GitHub Notification of comment by makxdekkers
Please view or discuss this issue at using your GitHub account

Received on Sunday, 23 June 2019 10:45:39 UTC