Dxwg: vCard and FOAF?

[riccardoAlbertoni]

Submitted on 21 Jun 2019:

https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Jun/0003.html

Quoting:

In relation to the current draft [1], have you considered simply allow both FOAF and vCard to be used for people and organisations based properties?

It seems slightly strange to limit vCard just for the Contact Point property, when it can express the Creator and Publisher as well.
And FOAF can also express the Contact Point.

Cheers - Renato

[1] https://www.w3.org/TR/vocab-dcat-2/
[2] https://www.w3.org/TR/vocab-dcat-2/#Property:resource_contact_point

[jakubklimek]

One point against doing this is that it complicates interoperability instead of improving it. If one publisher uses foaf and another one vcard, the consumer has to know both, has to know which is used by which publisher etc. Compared to specifying one and relying on everyone using the one.

[danbri]

you could also use Schema.org! :)

On Fri, 21 Jun 2019 at 13:47, Jakub Klímek [e-mail] wrote:

One point against doing this is that it complicates interoperability
instead of improving it. If one publisher uses foaf and another one vcard,
the consumer has to know both, has to know which is used by which publisher
etc. Compared to specifying one and relying on everyone using the one.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/w3c/dxwg/issues/955?email_source=notifications&email_token=AABJSGJ6BQDTZA2LV73TZBDP3TEXJA5CNFSM4H2RIYCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYILXGA#issuecomment-504413080,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABJSGI6OBNGP5Z3DGZJWZDP3TEXJANCNFSM4H2RIYCA
.

[agbeltran]

We had a previous discussion about this at https://github.com/w3c/dxwg/issues/109

The conclusion was that "the property is contactPoint so it is contact information that is expected.
General descriptions of agents may be needed somewhere else, but not here." (see https://github.com/w3c/dxwg/issues/109#issuecomment-404710582)

[ltrani]

I would definitely appreciate a change or clarification here (maybe more examples?).
We started piloting the application of DCAT2 and we are very happy with the new features. However, the intended usage of FOAF and VCARD and how they could/should be combined/related are aspects that can generate confusion (especially to new DCAT users).

For instance, suppose the following situation:
John is the creator of a dataset and he is also the contactPoint for the same dataset.
In the current situation one would have to create a foaf:Person for the role creator. Then presumably he would create a vcard:Individual for the contact point.
He ends up with two unrelated concepts (and their IDs), unless he defines esplicitely an additional relationship between the two.
E.g.:
<JohnID> a foaf:Person;
foaf:name "John";
...
<JohnContactID> a vcard:Individual;
vcard:hasEmail [email protected]

Moving towards Schema.org could be helpful and simplify things:
<JohnID> a schema:Person;
schema:name "John";
schema:contactPoint <JohnContact2ID>

<JohnContact2ID> a schema:ContactPoint;
schema:email [email protected]

From a conceptual point of view both approaches are valid but from a practical point of view the latter IMHO is more intuitive

[andrea-perego]

I have no strong feeling about using or not interchangeably FOAF and vCard, although there may be some concerns in terms of backward compatibility for DCAT - as already mentioned by @jakubklimek

On a related note (and maybe not completely relevant to solve this issue), I include below some considerations about the use of dcat:contactPoint, that could be relevant to the problem reported by @ltrani:

Based on my experience, authors and contact points should ideally be different. The reason why you add a contact point, is to indicate a "contact" which is stable in the mid-/long-term, whereas authors are included for other purposes - e.g., attribution. Looking, e.g., at scientific data (which is where dataset authors are more likely to be indicated compared with government data), since research teams are frequently changing, the most "stable" contact point is the "team", not the single scientist.

We saw this also in the work on the JRC Data Catalogue, where the recommendation is to specify a functional / team mailbox as a contact point, and not the one of an individual.

Always taking as example the JRC Data Catalogue, another thing we realised is that what is really and only needed for the contact point is either an email address or the URL of a contact page. Other information, besides being not of very much use, has the risk of becoming obsolete (postal address, the name of the contact point, etc. may change over time, and people forget to update it). Based on that, we have also been seriously thinking to simplify the specification of the contact point by removing all the unnecessary statements (including rdf:type), and using the email / contact page as the object of dct:contactPoint - e.g.:

turtle a:Dataset a dcat:Dataset ; dcat:contactPoint <mailto:[email protected]> ; .

[riannella]

Perhaps consider following the approach of the W3C POE WG for the ODRL recommendation in which it allowed for a range of current agent descriptions:
https://www.w3.org/TR/odrl-vocab/#term-Party

[makxdekkers]

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” (http://xmlns.com/foaf/spec/#term_Person) versus vcard:Individual=”An object representing a single person or entity” (https://www.w3.org/TR/vcard-rdf/#d4e1749). 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 https://lov.linkeddata.es/dataset/lov/terms?q=person – would we add those too? I understand from Renato’s example that the ODRL people thought that schema.org, 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.

[makxdekkers]

@andrea-perego I understand what you're doing there and I agree it is a practical solution, but I also think that you're bulldozering through fundamental aspects of SemWb/LinkedData by using an e-mail address as the object of dcat:contactPoint. You imply, and require a consuming application to understand, that it is 'shorthand' for dcat:contactPoint [ vcard:hasEmail "mailto:[email protected]" ]. However, any consuming application that is not aware of that shortcut, would expect to get either a URI pointing to an object with some vcard statements, or a blank node with some vcard statements, and thus would fail to correctly act on receiving that bit of data.
It looks to me that we are getting into a situation that a metadata creator finds a property that looks like it is useful to carry information, and then put data that is available as the object/value without bothering about domains and ranges.
In my mind, it means that people can forget about specifications and rules and just do whatever they like. Interoperability, that way, goes out the window.
You could mint your own property jrc:contactEmail for your own community, creating interoperability within your community, and not break interoperability with the wider world.

[andrea-perego]

You're right, @makxdekkers , and actually I said "we have also been seriously thinking to ..." implying that we are not going that way (and exactly for the reasons you say).

My point was more in reply to @ltrani 's argument, and to note that there are good reasons why dataset authors and dataset contact points should not always correspond to the same agents.

[riannella]

@makxdekkers

1) The FOAF description for Person says "The Person class represents people."
(in this case the description is more useful than the definition :-)

2) The POE WG (ODRL) choose those agent options as the community suggested they where the most useful. No doubt things will change in the future!

3) My point is not to add more options, but to be consistent in the two that have been already chosen.

[makxdekkers]

@riannella

1. I guess there might have been some confusion over the semantic shift that took place between https://www.w3.org/Submission/2010/SUBM-vcard-rdf-20100120/ -- where I think, but correct me if I am wrong, the object was a representation of a business card -- and https://www.w3.org/TR/2013/WD-vcard-rdf-20130502/ -- where the object represented persons, organisations etc. That shift came during the development of DCAT and therefore might not have been fully appreciated.
2. Indeed, that future change would worry me. My view is that we should try to make the standard as stable as possible. Why would you want to keep adding options?
3. In my opinion, the two properties in DCAT dct:publisher and dcat:contantPoint are semantically different as their intention is different -- one to link to an organisation, the other to link to contact information. Giving them the same range is, in my opinion, creating more confusion for no other reason than elegance of design, which for me is not a good reason in itself.

[smrgeoinfo]

Coming at this from the ISO 19115 perspective, it looks like this:
pointOfContact is a role filled by an agent (ResponsibleParty), who might be a person, a role-filler in an organization (e.g. 'metadata curator') or simply an organization.
Persons, Role-fillers and organizations (agents or ResponsibleParties) have contactInformation (ContactInfo); telephone numbers or e-mails seem to be most useful, but they become stale--good metadata requires maintenance.
In this discussion, it seems that 'contactPoint' is being interpreted variously as 'pointOfContact' role or as 'contactInformation'.
Per @ltrani 's suggestion above, it seems that schema.org provides a clearer disambiguation of these concepts than foaf or vcard

[ltrani]

@makxdekkers I agree that the two properties are semantically different but I don’t think that it is only a matter of elegance of design. In my view there is also a component of usability due to overlapping definitions.
In the current situation you are implicitly making quite strong assumptions and suggesting choices that affect implementation e.g as @andrea-perego pointed out the same physical person should not be creator and contact point of one resource.

However, even assuming that scenario, things can get complicated.
For instance, when a person is contact point for a Dataset she needs to be a vcard:Individual. If the same physical person acts as creator of (another) dataset she needs to be a foaf:Agent.
Similarly, if an organisation is publisher and contact point (of different resources).

Therefore you end up having the same physical person duplicated. This implies additional work to keep consistency and align IDs (with extra relationships) and related risks.

From my experience in EPOS-DCAT-AP, it is already quite challenging dealing with integration in a multi-organisational, multi-disciplinary context. There you usually have a person that has a number of representations and IDs e.g. ORCID, SCOPUSID; and you wish to combine them in one entity associated with multiple IDs and roles.
This is why we went for Schema.org example

In my view introducing alignments or extending ranges might make the model more robust and enable users to decide how to apply roles and responsibilities. It would also reduce the need for additional future options.

[makxdekkers]

@smrgeoinfo I agree that contactPoint can be seen as 'someone to contact' -- which I think is where @riannella comes from -- and 'contact information' -- which what the intention in DCAT 2014 was. That's what I called the difference in intention between dct:publisher and dcat:contactPoint.

@ltrani I don't think your example implies that the person is duplicated. It would be perfectly possible for a person's URI to point to something that is both a foaf:Person and a vcard:Individual. No need for two URIs.

And on @ltrani's last point: it indeed gives users, namely metadata creators, more flexibility so they can use whatever they like best, but the consumers pay the price for that flexibility as they will have to create consuming software that needs to understand all the flexibility. This is what worries me, and in this case it creates immediate interoperability problems.

[smrgeoinfo]

+1 on limiting flexibility to favor interoperability.

[ltrani]

@makxdekkers

It would be perfectly possible for a person's URI to point to something that is both a foaf:Person and a vcard:Individual. No need for two URIs.

you mean something like <#meURI> a vcard:Individual, foaf:Person . ?

[makxdekkers]

@ltrani yes

[ltrani]

Ok but then you are moving the issue on the users' side aren't you?
From the point of view of the interoperability I am not sure whether this solution would make things easier as it might encourage mix and match and proliferation of application profiles.
E.g. when it comes to express name which vocabulary should I use foaf:name or vcard:name or both?
Why not simplify and have just one choice that represents the concept of Agent with contact point as one of its attributes?

[makxdekkers]

@ltrani I was just responding to your point that you would need to create two URIs, which I argued was not necessary.
Which properties to use from either FOAF or VCard is an application choice. DCAT just specifies that the object of dct:publisher is a foaf:Agent (or a dct:Agent which is the same) and that the object of dcat:contactPoint is a VCard:Kind. An application profile or a community guideline could further specify which properties from FOAF or VCard need to be provided.
In many cases that I've seen, it is often the case, and it may actually be recommended, as @andrea-perego mentioned, that the contact point is a functional telephone number or mailbox, one that is specific for questions or comments related to the Dataset, not the general mailbox of an organisation.
You can of course disagree with the approach but that is how it was designed, and that's how it has been used.
If we want to change this, we need to make sure that the intention is somehow preserved, that a new approach makes things better and that a necessary change in existing implementations has a clear benefit, for example in increased Interoperability.

[riannella]

@makxdekkers Yes, I see creator, publisher, contact as three roles.

[makxdekkers]

Dear Renato,

We have discussed your suggestion to change the specification of DCAT, where you argued that vCard, which is currently only specified as the recommendation for dcat:contactPoint, could also be used for properties to identify persons and organisations, i.e. dct:creator and dct:publisher.
While we appreciate your suggestion and understand that in your opinion this would increase consistency across the specification, we have decided not to make the change you have asked for.

The reason for our decision is two-fold:

1. In the current specification, there is an explicit semantic difference between the agent-related properties, defined by DCMI as linking to an agent, i.e. organisation or person, and dcat:contactPoint which is defined as linking to contact information for the catalogued resource. This is the reason that the recommendation for dcat:contactPoint, to use vCard, is different from the recommendation for the agent-related properties, to use resources of type foaf:Agent. In our opinion, this difference in intention between the properties is important to preserve.

2. We have not seen evidence that the current specification hinders or breaks implementations. In general, one of the criteria to make changes is that such changes are necessary to repair errors that negatively affect interoperability or to add features that increase interoperability, and we consider this change not essential for increased interoperability.

Having said that, the fact that we’re not adding vCard as a recommendation for the agent-related properties does not mean, within the context of the Open Word Assumption, that it would be illegal to use vCard properties for the description of agents, as long as these vCard properties are applied to an entity that is an instance of the class foaf:Agent; it is just that we don’t consider it to be necessary to make the additional recommendation.

As we understand there may be some confusion over the usage of vCard for dcat:contactPoint, we will add some examples to the specification to make its use clearer.

Kind regards, Makx Dekkers

Response also posted at https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Jul/0005.html