- From: Johan De Smedt <johan.de-smedt@tenforce.com>
- Date: Sat, 14 Aug 2010 17:44:27 +0200
- To: "'Antoine Isaac'" <aisaac@few.vu.nl>, <public-esw-thes@w3.org>
- Cc: "'SKOS'" <public-esw-thes@w3.org>
Hi Antoine, I completely agree that "good" publishing practice ensures that all inference is done at the publisher side. The relevance in coming to a standard on artifacts such as - a s:ConceptGroup class - a s:subScheme and s:isSubSchemeOf properties (between concept schemes) [provides extra rules for skos:inScheme] - a s:classifyingTaxonomy and s:isClassifyingTaxonomyFor properties (between concept schemes) [provides for an interpretation of a dc:subject between skos:Concept of a classifying taxonomy and a classified concept scheme] are more relevant for interchangeability of concept-schemes between back-office concept scheme management systems than for indexing and search applications. Kind Regards, Johan De Smedt > -----Original Message----- > From: public-esw-thes-request@w3.org [mailto:public-esw-thes- > request@w3.org] On Behalf Of Antoine Isaac > Sent: Saturday, 14 August, 2010 12:38 > To: public-esw-thes@w3.org > Cc: SKOS > Subject: 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 15:45:06 UTC