dcat:themeTaxonomy - check constraints

[dr-shorthair]

In DCAT v1 the property dcat:themeTaxonomy is axiomatized

dcat:themeTaxonomy
  rdf:type owl:ObjectProperty ;
  rdfs:domain dcat:Catalog ;
  rdfs:range skos:ConceptScheme ;
.

1. Verify that the range is appropriate and necessary
2. Verify that the domain is appropriate and necessary (see Review global domain axioms on dcat properties #110)
3. Consider whether any guarded constraints (using owl:Restriction) should be introduced (see Use owl:Restriction constraints to bind DC properties to DCAT classes  #105)

[dr-shorthair]

This looks like a very specific DCAT capability that is appropriately modeled

[dr-shorthair]

No-one advocating for changes here.

I'll bring this proposition to the next DCAT team telecon for resolution.

[dr-shorthair]

+1 to no change

[dr-shorthair]

Goal is to support dataset catalogs, not provide general purpose predicates for the semantic web

https://www.w3.org/2018/03/21-dxwgdcat-minutes
resolved: no change to domain/range of dcat:themeTaxonomy

[akuckartz]

I think that this resolution is inconsistent with the others where the domain was removed. But that is just my view.

[akuckartz]

Accessing https://www.w3.org/2018/03/21-dxwgdcat-minutes results in a 403 error.

[dr-shorthair]

Yes - there was a bug generating the minutes. I clipped a copy of the IRC log and have forwarded it to W3C to process.

[dr-shorthair]

On consistency @akuckartz the argument is that dcat:themeTaxonomy is a specific predicate to link a skos:ConceptScheme to a dcat:Catalog whose members may use elements from the concept scheme. It is not a goal of DCAT to be a source of general purpose predicates for the semantic web, it is to support catalogs of datasets and related resources. So it is reasonable for a catalog to indicate which classification systems are in scope for its members.

[arminhaller]

As mentioned in the telco, I think the naming of the property is inconsistent with the purpose that it should be used to indicate the classification scheme for a Catalog. If that is the desired semantics, then catalogTheme or themeCatalog would certainly make sense. It if is generically called themeTaxonomy, I would not expect a domain. I was voting 0, though, no objection, but I agree with @akuckartz that it is inconsistent.

[pwin]

are we still leaving the range constraint of dcat:themeTaxonomy in place? - it precludes using a skos:Collection at present

[dr-shorthair]

Good point @pwin
Many potential vocabularies that would provide a set of theme classifiers are not organized as skos:ConceptSchemes - in fact many are not SKOS at all, though they are nevertheless good choices.
I suggest dropping the global range constraint (and maybe add sdo:rangeIncludes skos:ConceptScheme, skos:Collection which is a non-exclusive statement).

[pwin]

I agree Simon

…

On Thu, 25 Apr 2019, 22:49 Simon Cox, ***@***.***> wrote: Good point @pwin <https://github.com/pwin> Many potential vocabularies that would provide a set of theme classifiers are not organized as skos:ConceptSchemes - in fact many are not SKOS at all, though they are nevertheless good choices. I suggest dropping the global range constraint (and maybe add sdo:rangeIncludes skos:ConceptScheme, skos:Collection which is a non-exclusive statement). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#119 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIFYTETNJMX3FPTNGSNV5LPSIRPVANCNFSM4EQYWDUA> .

[davebrowning]

Core issue resolved here, and actioned some time ago. Use of sdo:rangeIncludes tracked via #912. I think we can close this one.

[pwin]

agreed