RE: ISSUE-160: Allowing collections in semantic relationships

Hi Johan!

If each micro-thesaurus is a Concept Scheme:
- a domain could be a collection of micro-thesauri
- Eurovoc could be a collection of domains

Collections can have concepts and collections as members, but no ConceptScheme. Right?

Also in Eurovoc (and ISO 2788) is pre-coordination. The most famous example is "Minerval" which means "tuition fee" in Belgium. In Eurovoc, you have a relation:
Minerval USE (Belgium AND Tuition fee)
How pre-coordination is represented in SKOS?

Christophe

--- En date de : Mar 16.12.08, Johan De Smedt <Johan.De-smedt@tenforce.com> a écrit :

> De: Johan De Smedt <Johan.De-smedt@tenforce.com>
> Objet: RE: ISSUE-160: Allowing collections in semantic relationships
> À: "Dupriez Christophe" <christophe_dupriez@yahoo.fr>, "Aida Slavic" <aida@acorweb.net>, "Thomas Baker" <baker@sub.uni-goettingen.de>
> Cc: "Antoine Isaac" <aisaac@few.vu.nl>, "public-swd-wg@w3.org" <public-swd-wg@w3.org>, "public-esw-thes@w3.org" <public-esw-thes@w3.org>
> Date: Mardi 16 Décembre 2008, 15h05
> Dear,
> 
> As far as Eurovoc is concerned, the following modelling can
> go as an extension.
> 
> Eurovoc
> - it is one thesaurus (Concept scheme)
> - It has several micro-thesauri (also concept scheme), 
>   - ranging over a subset of the concepts in the overall
> thesaurus
>   - for the concepts considered in the micro-thesaurus, no
> other associations hold than those present in the overall
> thesaurus
> - The micro thesauri are grouped (actually partitioned)
> into domains
> 
> Structural extensions of skos required to model this
> - a construct/constraint to validate that a micro-thesaurus
> is ranging over a subset of concepts of the overall
> thesaurus
>   (example: the Concept group)
> - a Domain as a superstructure of micro-thesauri
>   (could be a "super" Concept group)
> 
> Typically in thesauri there are thesaurus array.
> The difference as I understand it between a thesaurus arry
> and a concept group is that the concepts in an array are
> siblings
> whereas the concepts in a concept group do not have this
> constraint.
> 
> Thanks for comments.
> 
> Johan De Smedt
> 
> -----Original Message-----
> From: public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org] On Behalf Of Dupriez
> Christophe
> Sent: Tuesday, 16 December, 2008 14:44
> To: Aida Slavic; Thomas Baker
> Cc: Antoine Isaac; public-swd-wg@w3.org;
> public-esw-thes@w3.org
> Subject: Re: ISSUE-160: Allowing collections in semantic
> relationships
> 
> 
> Hi Aida and Thomas,
> 
> First I see that my very first answer to Aida did not went
> thru:
> 
> --- Reaction to first Aida message:
> 
> I strongly support the position of Aida. We need a standard
> to represent correctly the proeminent features of what we
> have doing since the 80s. At least: Eurovoc which is a very
> good example of ISO 5964; MeSH which is the de-facto
> standard for all life sciences.
> 
> In a way, I would say the ISO standards (monolingual,
> multilingual thesaurus) which has always been a reference
> for all the profession + MeSH which is the most succesful
> big thesaurus are the MINIMA for SKOS.
> 
> Personnaly, I am happy with the concept of Collection to
> represent an arbitrary subset within a Scheme
> ("purpose" oriented). For example in a business
> system, "userLangage" can be the collection within
> the scheme "language" of the languages supported
> to interact with users.
> 
> Looking at the MeSH, there is an entity which looks like
> what you sometimes call a Collection: the Descriptor. The
> Descriptor is group of Concept (in the meaning of MeSH and
> SKOS) that are "blurred" together for indexing and
> retrieval purposes.
> http://www.nlm.nih.gov/mesh/concept_structure.html
> http://www.nlm.nih.gov/mesh/redefine.html
> http://www.nlm.nih.gov/mesh/2009/download/xml_data_elements.html
> 
> Descriptors are put in a classification tree
> (broader/narrower hierarchies for indexing/retrieval
> purpose: not for "reasoning" purposes).
> Descriptors and their hierarchies are retrieval tools (for
> humans), not reasoning tools (for machines).
> 
> SKOS would definitively benefit of a structured work taking
> ISO standards and MeSH and then look at their direct, simple
> and future proof representation in SKOS. We must build on
> past practical experience.
> 
> I would like here to state what is for me the major
> difference between SKOS and OWL... SKOS is to provide
> control data for a tool which links users and applications
> (terms, translations, synonyms, indexing/retrieval
> hierarchies, classification linking users to concepts). OWL
> is to provide control data for software application
> decisions (logical relations between concepts).
> 
> If this is true, SKOS must provide the necessary data to
> "drive" the users from their representation of the
> world to the concepts managed by the computer application
> (and vice-versa: to expose the application in a meaningful
> way for users).
> 
> I work in a Poison Centre where those considerations are
> judged in the context of vital/urgent retrieval and analysis
> of information. We use thesauri for decades and we are
> looking to SKOS to make them future proof.
> 
> ---- Following Thomas message:
> 
> I agree with you "in theory". The practician
> problem I have is that, unlike UniMARC and other libraries
> initiatives of the past, it is very difficult to find groups
> who work to create the DCMI profile for a given need. Also
> grammar of DC fields content is not precisely specified like
> what MARC+ISBD is providing.
> 
> I am working with medical articles (Medline XML is de facto
> standard), music records (not for sale, for selection by
> conductors), music scores and regular documents. I wanted to
> align my DC use to existing profiles but I did not found any
> group working on this. Finally, I made my own and I will
> adapt to any future standard using XSLT crosswalks. It is
> also not so difficult to change field names in DSpace
> applications.
> 
> With SKOS, we are looking to define a sizeable and
> consistent nucleus (able to cope with known needs) that can
> be enriched with RDF if one wants to address unforeseen
> needs. I used SKOS as a data model for an application
> integrated into DSpace and I am rather happy for now (live
> production will start in following weeks). It imports
> ConceptSchemes from SQL views, Tab delimited files, XML and
> export it to XML and through a Java API. I still have to add
> RIO to import/export RDF triples. But I have an XSD for an
> XML representation of a SKOS data structure (which is
> something one could want to standardize also). The XML files
> can be edited with JAXE for instance. Supporting RDF will
> allow my users to use Protege/SKOS.
> 
> Have a nice day,
> 
> Christophe
> 
> --- En date de : Mar 16.12.08, Thomas Baker
> <baker@sub.uni-goettingen.de> a écrit :
> 
> > De: Thomas Baker <baker@sub.uni-goettingen.de>
> > Objet: Re: ISSUE-160: Allowing collections in semantic
> relationships
> > À: "Dupriez Christophe"
> <christophe_dupriez@yahoo.fr>
> > Cc: "Aida Slavic" <aida@acorweb.net>,
> "Antoine Isaac" <aisaac@few.vu.nl>,
> "public-swd-wg@w3.org"
> <public-swd-wg@w3.org>,
> "public-esw-thes@w3.org"
> <public-esw-thes@w3.org>
> > Date: Mardi 16 Décembre 2008, 12h14
> > Hi Christophe,
> > 
> > On Tue, Dec 16, 2008 at 09:59:56AM +0000, Dupriez
> > Christophe wrote:
> > > MARC is very complex, OK. Dublin Core has
> provided a
> > lowest
> > > common denominator for exchanges between human
> users.
> > But
> > > Dublin Core has forgotten many of MARC qualities
> > (semantical
> > > precision for instance) and has not really
> benefitted
> > from
> > > the knowledge of MARC pitfalls (semantical
> adequation
> > of
> > > data for foreseen real purposes). Dublin Core is
> > correct for
> > > "information discovery" but is now used
> for
> > "information
> > > management" which is a painful problem.
> > 
> > I wanted to point out that "Dublin Core" is
> more
> > than a set
> > of fifteen elements used with string values (a usage
> which
> > is now referred to as "Simple Dublin Core").
> > 
> > The fifteen elements are part of a larger vocabulary
> > "DCMI
> > Metadata Terms" [1] which, as RDF properties and
> > classes,
> > are just as extensible as properties and classes in
> SKOS.
> > A "Dublin Core application profile" [2] uses
> > properties
> > from RDF vocabularies, as needed, to address specific
> real
> > purposes.  Most of the properties in DCMI Metadata
> Terms
> > also
> > have formally defined ranges -- more for purposes of
> > machine
> > processing than for exchanges between human users.
> > 
> > There is an interesting parallel between the design
> > trade-offs
> > described by Antoine with respect to the specificity
> or
> > generic
> > nature of SKOS and the specificity of the RDF
> vocabularies
> > defined around the fifteen-element Dublin Core.  I do
> not
> > believe there is a "perfect" balance between
> > simplicity and
> > complexity; rather, the solution lies in providing
> > mechanisms
> > for principled extensibility.
> > 
> > I'm not sure if this addresses your point about
> > "semantical
> > adequation of data", but the extensibility of the
> > vocabularies plus the notion of mixed-vocabulary
> profiles
> > means that profiles can be designed to be as complex
> or
> > management-oriented as needed.
> > 
> > Tom (who also works with DCMI)
> > 
> > [1] http://dublincore.org/documents/dcmi-terms/ (see
> also
> >     http://yoyodesign.org/doc/dcmi/dcmi-terms/ in
> French)
> > [2]
> >
> http://dublincore.org/documents/2008/01/14/singapore-framework/
> > 
> > -- 
> > Tom Baker <tbaker@tbaker.de>

Received on Tuesday, 16 December 2008 14:55:51 UTC