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

Hi everyone,

In the STITCH project we had some vocabularies that were also organized as "families" of concept schemes [1], and I think the pattern you suggest could apply to them without too much trouble.

I am however uncomfortable about data publishers not materializing the inScheme triples that can be inferred from the "most specific" inSchemes and the subSchemeOf links between concept schemes. This puts the burden of semantic inferencing on the data consumers, and I don't like penalizing the ones that need the general scheme (say, all LCSH) over the specific parts (say, LCSH genres).

Cheers,

Antoine

[1] see the RAMEAU and "Brinkman" vocabularies that you can explore from http://stitch.cs.vu.nl/repository (more specifically at http://eculture.cs.vu.nl:48080/vocreptags/autocompleteplus.jsp  now)



> Hi Tom and Johan
>
> Thanks for unearthing this thread. I agree with Johan's precisions
> below, unsurprisingly so since we have munched this stuff together in
> the framework of the EUROVOC model :)
>
> As per EUROVOC and LSCH examples, the most obvious use case is indeed to
> have a general (large) concept scheme organized in parts (not
> necessarily disjoint), and the skos:inScheme declarations made at the
> lower possible level (the parts),  belonging to the general scheme being
> inferred based on the property chain quoted by Johan.
>
> But to address the more general questions set by Tom, there is indeed no
> guarantee in an open world that the intensional declaration of concept
> schemes inclusion is validated in extension in the life cycle of the
> concept schemes. But such an intensional declaration by concept schemes
> initial publishers (aka owners) would put guidelines that further
> vocabulary extensions could leverage or not i.e. based on partOf
> declarations, one can entail new inScheme triples being free to validate
> them or not.
>
> Bernard
>
>
> 2010/8/12 Johan De Smedt <johan.de-smedt@tenforce.com
> <mailto:johan.de-smedt@tenforce.com>>
>
>     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> [mailto:public-esw-thes-
>     <mailto:public-esw-thes->
>      > request@w3.org <mailto: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 <mailto: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 <mailto:tbaker@tbaker.de>>
>      >
>
>
>
>
>
> --
> Bernard Vatant
> Senior Consultant
> Vocabulary & Data Engineering
> Tel:       +33 (0) 971 488 459
> Mail: bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
> ----------------------------------------------------
> Mondeca
> 3, cité Nollez 75018 Paris France
> Web: http://www.mondeca.com
> Blog: http://mondeca.wordpress.com
> ----------------------------------------------------

Received on Saturday, 14 August 2010 10:39:08 UTC