RE: Using dcterms:hasPart for skos:ConceptScheme hierarchies ?

Hi,

The "ConceptGroup" artifact is very useful.
However, if a "micro-thesaurus" needs to be published/used on its own
account,
it is handy that the "ConceptGroup" class need not be disjoint with
"ConceptScheme",
though surely, not every concept group needs to be a concept scheme.

An explicit relation between concept-schemes A and B:
- A hasSubScheme B is very useful
Such a property (and its inverse subSchemeOf) could be used to declare
inference rules (property chains).
- C inScheme B, B subSchemeOf A -> C inScheme A

A second approach (for large SKOS) is that a thesaurus and a taxonomy are
combined.
- A taxonomy classifies resources/documents according to (e.g.) business
domains
- a subject register or thesaurus is used to tag the same set of documents
for search and retrieval purposes by (e.g.) subject matter.
Typically the thesaurus concepts "are related to (belong to)" 1 or more
concepts in the taxonomy.
This "are related to (belong to)" nicely fits in the concept group approach.
- the concept groups being defined by a taxonomy concept
- the thesaurus concepts being members of the those concept groups
So the concept group class is in this approach not disjoint from concept.
This relation between thesaurus concepts and taxonomy concepts is not
unambiguously
expressed using the SKSO semantic (or matching) properties.  (and typically
use specific SKOS extensions).

Do these approaches fit with abstractions of typical thesauri that are
currently being published in SKOS ?
Are these abstractions general and significant enough to merit a common
solution ?

Kind Regards,

Johan De Smedt 
> -----Original Message-----
> From: public-esw-thes-request@w3.org [mailto:public-esw-thes-
> request@w3.org] On Behalf Of Thomas Baker
> Sent: Wednesday, 11 August, 2010 20:56
> To: Bernard Vatant
> Cc: SKOS
> Subject: Re: Using dcterms:hasPart for skos:ConceptScheme hierarchies ?
> 
> Hi Bernard,
> 
> Catching up on this thread, and following up only to
> public-esw-thes@w3.org as per your request...
> 
> On Tue, Jun 15, 2010 at 01:07:25PM +0200, Bernard Vatant wrote:
> > Sorry for cross-posting, I'd like to attract attention of people from
> DC,
> > ISO and LoC. Please follow-up on SKOS list only to reduce noise.
> >
> > SKOS does not make provision for partitive relationships between
> instances
> > of ConceptScheme, such as division of a thesaurus into microthesauri.
> > ISO 25964 draft introduces the notion of ConceptGroup and possibility
> of
> > subgroups. But with no RDF model so far.
> > Published vocabularies in SKOS such as LCSH use a workaround by
> declaring
> > both the general and particular schemes of a concept, such as :
> >
> > <rdf:Description
> rdf:about="http://id.loc.gov/authorities/sh85060646#concept">
> >     ...
> >     <skos:prefLabel xml:lang="en">Hierarchies</skos:prefLabel>
> >     ...
> >     <skos:inScheme
> rdf:resource="http://id.loc.gov/authorities#topicalTerms"/>
> >     <skos:inScheme
> rdf:resource="http://id.loc.gov/authorities#conceptScheme"/>
> >     ...
> > </rdf:Description>
> >
> > One has to upload all the LSCH vocabulary (quite large) to figure out
> that
> > every other concept declaring <skos:inScheme rdf:resource="
> > http://id.loc.gov/authorities#topicalTerms"/> has also a declaration
> > <skos:inScheme
> rdf:resource="http://id.loc.gov/authorities#conceptScheme"/>
> > , meaning the extension of the latter includes the extension of the
> former.
> >
> > One would certainly prefer to have this declared up front in an
> intentional
> > way, avoiding the redundant declarations for each concept.
> > Seems to me that Dublin Core has provision for such declarations,
> e.g.,
> >
> > <http://id.loc.gov/authorities#topicalTerms>
> <http://purl.org/dc/terms/isPartOf>
> > <http://id.loc.gov/authorities#conceptScheme>
> > and/or
> > <http://id.loc.gov/authorities#conceptScheme>  <
> > http://purl.org/dc/terms/hasPart <http://purl.org/dc/terms/isPartOf>>
> <
> > http://id.loc.gov/authorities#topicalTerms>
> 
> I think you meant this last part simply to read:
> 
>     <http://id.loc.gov/authorities#conceptScheme>
>         <http://purl.org/dc/terms/isPartOf>
>             <http://id.loc.gov/authorities#topicalTerms>
> 
> > Such declarations could be available under something like
> > http://id.loc.gov/authorities.rdf.  BTW currently the two concept
> scheme
> > URIs redirect to the same HTML page at http://id.loc.gov/authorities,
> so
> > there is no formal description of the concept scheme available
> outside the
> > whole LCSH files (quite large, as said above.)
> >
> > To sum it up, questions both to DC and SKOS folks
> >
> > - Is such a use of dcterms:isPartOf or dcterms:hasPart compatible
> with the
> > letter and spirit of both SKOS and DC ?
> 
> >From a DC point of view -- in my opinion -- it looks perfectly
> correct.  Also from a SKOS point of view.
> 
> > - If yes, could it be raised to the level of recommended practice
> endorsed
> > by both communities?
> 
> DCMI does have a body that examines issues related to
> semantics -- the Usage Board -- however the Usage Board does
> not currently have a mechanism for endorsing practices at this
> level of granularity.  Now that the Semantic Web Deployment
> Working Group has been closed, on the other hand, the "SKOS
> community" does not have a formal, organizational context for
> discussing and commenting on questions of recommended practice.
> 
> Perhaps this is a problem, and I'd love to hear suggestions
> on how we might collectively organize ourselves to provide this
> sort of ongoing review of emerging practice, both organizationally
> and in terms of human resources.
> 
> In the meantime, adopting this approach in a prominent SKOS
> implementation such as the ID service at LoC -- and documenting
> the rationale for doing so -- would at least provide a good
> example that others could follow.
> 
> Drilling down a bit further on the suggestion at hand:
> 
> > meaning the extension of the latter includes the extension of the
> former.
> 
> This does seems consistent with the definition of isPartOf:
> 
>     A related resource in which the described resource is
>     physically or logically included.
> 
> However, I think you are aiming for a strict logical
> interpretation (e.g., "the extension of the latter includes
> the extension of the former") -- more than just a case of a
> related resource in which the described resource is "more or
> less" included.  I think you are aiming for a declaration that
> could reliably be used by implementations with the certainty
> that the latter precisely includes the former.
> 
> If so, then I would have some question as to whether,
> in practice, one could expect the guideline to be applied
> consistently enough to guarantee that the strict interpretation
> were always valid -- especially in cases where concept schemes
> (or parts of concept schemes) are continually evolving in a
> distributed or loosely coordinated manner.
> 
> Might there be situations in which the logical inclusion of
> one scheme within another could be violated by subsequent
> developments, rendering originally precise isPartOf statements
> only "approximately" correct?  Could this imprecision damage
> implementations?  It looks to me, on second glance, like
> sorting out a strict formal interpretation could take more
> discussion than at first glance seemed necessary...
> 
> Tom
> 
> --
> Thomas Baker <tbaker@tbaker.de>
>

Received on Thursday, 12 August 2010 06:18:47 UTC