- From: Makx Dekkers <makx@makxdekkers.com>
- Date: Tue, 26 Mar 2013 16:27:34 +0100
- To: "'Richard Cyganiak'" <richard@cyganiak.de>
- Cc: "'Public GLD WG'" <public-gld-wg@w3.org>
Richard,
> > From your response I understand that skos:Concepts that are not a
> member
> > in a skos:ConceptScheme are not allowed as objects of dcat:theme.
> > Correct?
>
> That's the rule as written in the spec.
>
> > What is the reason behind that requirement?
>
> So that one can discover the entire concept scheme in use for the
> given catalog.
>
I don't understand this.
First of all, you seem to imply that there will only be one concept
scheme ("the entire concept scheme" in singular) in use for the
catalogue. I could have datasets that satisfy the requirement that all
themes are part of a theme taxonomy, but those might be from more than
one concept scheme. Is that not allowed?
Secondly, discovering "the entire concept scheme" is not possible from
looking only at the themes. Not all the concepts in the concept scheme
may be used. You can only find out which concept schemes are actually
used for the themes. If you also require that the concept scheme is
specified as themeTaxonomy it gets easier but you still have to go to
the concept scheme URI to find the entire concept scheme (the complete
collection of concepts in the scheme).
But most of all, I don't understand why "discovering the entire concept
scheme" is a requirement. Are you saying that an application that uses
DCAT without being able to find out the concept scheme(s) used is in
some sense not useful?
Please note that I am not saying that it is not useful to have theme
taxonomies and themes specified. I am actually looking into making them
mandatory for the Application Profile we are working on, but I just like
to know why those rules are necessary for the base specification.
Makx.
Received on Tuesday, 26 March 2013 15:28:05 UTC