pietercolpaert
commented
1 month ago I think we can do something similar as with dcat:distribution here: if you provide it as a blank node it will be an embedded entity, and if you provide it as an IRI, then you must provide it as a standalone entity so that a harvester can decide on their own what the best source for a certain contact point would be?
In my experience a Contact Point is a like contact details (email or phone number) and nothing more. It is different from an agent which has some legal status.
In many (public) organisations which are very large, departments have unique contact details but no legal status. It means that the publisher of two datasets from the same organisation but are managed by 2 distinct groups/people, which even might not know eachother. As this is an internal organisational structure, the contact details may stay to the outside the same, but internally this might reorganise from one moment to another. That is the reason why such lightweight "organisational" view is hard to formally manage. It sometimes even is not relevant for the outside.
For that reason in DCAT-AP is never pushed for a formal management of contact details (contact point).
Therefore I ask about the motivation for this, as so far on this entity in DCAT-AP no formal management is expected. E.g. in GeoDCAT-AP this is just the result of a mapping from unnamed ISO XML blocks.