Related to #110

There is an initial UC draft here, please review!

Thanks, @jpullmann .

+1 from me, modulo a couple of fixes:

s/implying, that/implying that /

s/apporpiate/appropriate/

Thanks @jpullmann

I think addressing this Use Case as posed is impossible: we can't tackle domain & range restrictions for all properties all at once, they are different!

For the text as given so far:

s/weaking/weakening/
s/a property a part of guidance/a property, some of the guidance/
s/compensated by apporpiate/compensated for by appropriate/

Considering just the dcat:contactPoint domain & range:

• demoing the use of dcat:contactPoint with a relaxed domain:
  • The use of dcat:contactPoint for a catalogue is obviously appropriate and given that there are many circumstances within which people would want to contact the catalog maintainers rather than the maintainers of a specific dataset. The data.gov.au catalog (a CKAN instance able to export DCAT) has a non-semantically-described web page "About" with "Contact Us" information including the main catalogue team email address [email protected]. This should be able to be represented, legally, as follows:

:Catalog_x a dcat:Catalog ;
    dct:title "data.gov.au" ; # the catalog is called this!
    dcat:contactPoint <[email protected]>
.

• demoing the use of dcat:contactPoint with a relaxed range:
  • In the example above, yes a VCard could be used but perhaps it's onerous so a range relaxation might be sensible to use (pointing to just an eamil address as above).

@nicholascar In terms of relaxing the range, what would you propose the range to be? Should it be something like dcat:ContactInfo, similar to schema:ContactPoint?
In the example you include, dcat:ContactPoint <[email protected]>, it seems like it's directly rdfs:Literal (like schema:email). Is that the intention?

I've re-written the proposed use-case to give us the lattitude to inspect all the global domain/range constraints. See ID51 draft

FWIW (since schema.org equivalents were mentioned) if the WG would like term mappings (expressed in RDFS/OWL) included officially in Schema.org, that ought to be pretty straightforward. We have a few already. They are just additional assertions included in https://github.com/schemaorg/schemaorg/blob/master/data/schema.rdfa or nearby, and some of them are also reflected into RDFa/RDFS in per-term pages, e.g. view-source: on http://schema.org/Event shows an equivalency to dcterms:Event. As soon as we all agree what the mappings are, raise an issue at Schema.org's github and we'll get them reflected over there.

This issue was addressed by #110 and linked issues.

I propose to close it.

Closing it, as no objections have been raised since flagged as due for closing.