Dear all,

As per Bernard's request, I am following up on this issue of
interest to the DC community by posting on the SKOS list [1]...

At issue is the semantics and use of the DCTERMS properties
hasPart and isPartOf when used to express the inclusion of
one SKOS concept scheme within another.

Tom

[1] http://lists.w3.org/Archives/Public/public-esw-thes/

On Wed, Aug 11, 2010 at 02:56:11PM -0400, Thomas Baker wrote:
> From: Thomas Baker <[log in to unmask]>
> To: Bernard Vatant <[log in to unmask]>
> Cc: SKOS <[log in to unmask]>
>
> Hi Bernard,
>
> Catching up on this thread, and following up only to
> [log in to unmask] 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 <[log in to unmask]>
>

--
Tom Baker <[log in to unmask]>