Agree with Dieter here,

would suggest to use the org:siteAdress property or a subproperty of it to do this instead: https://www.w3.org/TR/vocab-org/#org:siteAddress

As cpov:PublicOrganization is defined as a subClass of org:Organization it should have no conflict.

Thanks Dieter, you are correct. I'll change the range to schema:ContactPoint. Laurens, I'm in the middle of answering your point about using org:siteAddress (I'm arguing for using schema.org)

I would argue against org:siteAddress, since its domain is org:Site. An PublicOrganisation is not an org:Site.

I've been looking at this in more detail and I'm no longer sure that schema:contactPoint is correct, at least, not in the way it's presented. My reasoning is that, as Dieter points out, the range is schema:ContactPoint. Aside from disliking properties and classes with identical names except for the initial letter being capitalised, the schema:ContactPoint class uses schema:availableHours that takes a whole class as its value, whereas the simpler schema:openingHours just takes a structured string. The http://schema.org/OpeningHoursSpecification spec is detailed and, I notice, handles exceptions like "open every day except Christmas Day" but the markup needed is very large and complex. In my view, too complex for a core voc.

My proposal is to wield Occam's Razor, in this case, handily provided by schema.org's own get out clause which is that, rather than use definite domains and ranges, they say 'rangeIncludes' and 'domainIncludes.' This provides sufficient wiggle room for us to use the simpler schema:openingHours on a schema:ContactPoint. The alternatives are to go the whole way and use schema:ContactPoint -> hoursAvailable -> OpeningHoursSpecification OR not use schema.org terms at all.

This was resolved during the 17/11/16 meeting. As a result, Contact Point now has openingHours for regular opening hours and uses schema.org's method of indicating exceptional closing days, such as public holidays. It is perhaps noteworthy that this has prompted a positive discussion and likely change in schema.org, see https://github.com/schemaorg/schemaorg/issues/1444.