On point 1, as far as I understand, the Kind class is the umbrella class that includes Organization and Person so it looks to me like it is the right class
On point 2, I think it would make sense to allow other representations. What would the overarching class be?

Hmmm. Could be a Union class which includes vcard:Kind and foaf:Agent (the latter also gets you dct:Agent and org:Organization). Maybe also prov:Agent.

I'm reluctant to propose a new superclass though - these should be enough. The only problem is that vCard is so 'contact details' oriented, while foaf:Agent and its relatives are more conceptual, and better integrated into the rest of the ontology ecosystem.

+1 for a Union class of card:Kind and foaf:Agent

@dr-shorthair @arminhaller The problem that I see is that the object of dcat:contactPoint is "relevant contact information". An instance of foaf:Agent is a person or organisation, not its contact information. Of course the person or organisation may have contact information but it's not obvious how to get to that. This was a recurring issue with DCAT-AP and led to the guideline at https://joinup.ec.europa.eu/release/how-are-publisher-and-contact-point-modelled. Even if the range is widened to include foaf:Agent, I think there needs to be a statement somewhere that the instance metadata needs to include the contact information -- and I would suggest it then recommends the use of vCard, so that the data is interoperable.

I support requiring contact information, not just Agent identity for this property.

-1 for extending the range of dcat:contactPoint. VCard is a standard vocabulary for contact information and this precisely corresponds to what a contact point should be. I see no need to change this. It can be easily used like this (and we use it like this with no problems):

@prefix vcard2006:	<http://www.w3.org/2006/vcard/ns#> .
@prefix dcat:	<http://www.w3.org/ns/dcat#> .

<dataset> a dcat:Dataset;
 dcat:contactPoint <dataset/contact-point> .

<dataset/contact-point> a vcard2006:Organization ;
    vcard2006:fn "Ing. Jiří Šunka"@cs ;
    vcard2006:hasEmail "[email protected]" .

Creating an additional union class or relaxing the range in any way would only complicate processing of DCAT data and confuse both publishers and consumers. The fact that some publishers use this property with foaf:Agent simply means they do it wrong, not that DCAT should change. If there is need to connect an additional foaf:Agent (besides dct:publisher), it can always be done using another property, outside of DCAT.

If, for some reason, this should be dealt with in DCAT, then I would suggest adding another property rather than confusing the range of dcat:contactPoint with a union class, which is always harder to process and validate.

I agree - the property is contactPoint so it is contact information that is expected.
General descriptions of agents may be needed somewhere else, but not here.

By my reading, this discussion has concluded (with the result that contactPoint is fine as is) so I propose to close this issue.