Broader and narrower in Vocab

[Tony Linde]

> > Comments?
> >
> You got some :-)

And an excellent lot of comments, they are. Many thanks, Bernard.

> > concept to belong to more than one broader concept, but this is not,
> > AFAIK, possible in SKOS.
> >
> Oh, yes it is. SKOS allows multiple broader for one concept, and many

Right. The only examples I looked at only had the one and I've not yet got
to grips with ThManager to figure out how to do things.

Is there a decent tool for constructing SKOS vocabularies? Even better,
is/are there web-based interface(s) we could use for constructing and/or
viewing these vocabularies?

> See e.g. how multihierarchy is handled in the Web interface of the

I assume that that way of representing the multiple trees is just that
organisations chosen way. Ie, you could choose whichever way best
represented your own knowledge (or multiple ways I guess).

> There are different solutions to handle multiple hierarchies, one being
> to qualify ("color") the b/n links so that the multi-hierarchical graph
> is considered as the entangling of distinct graphs, in each of one

That sounds the best way forward. I assume it is best to enumerate the
relationship types that each graph will handle up front?

What would a set of SKOS declarations using more than one colour of graph
look like for astro-type terminology?

> please keep distinct the URI for the SKOS concept and the URI for the
> equivalent/similar/matching OWL class, so that you can identify very
> distinctly, e.g.,

I bow to your greater knowledge. Thanks for the advice.

T.

> -----Original Message-----
> From: Bernard Vatant [mailto:bernard.vatant at mondeca.com]
> Sent: 18 September 2007 16:16
> To: Tony Linde
> Cc: 'semantics'
> Subject: Re: Broader and narrower in Vocab
> 
> Hello all
> 
> Jumping in again for a few points about SKOS vs anything else :-) .
> >
> > Broader / narrower (b/n) might be said to simply be an indicator of
> > the direction of a relationship between two terms; it does not define
> > the relationship _type_. So the b/n relationship cosmology /
> > cosmicBackground is that of a ‘subject area includes topic’
> > relationship, Galaxy / seyfertGalaxy is a ‘type includes subtypes’
> > relationship, and solarSystem / planet is a ‘has component or part’
> > relationship.
> >
> Indeed. All the point of broader/narrower is to have poor semantics,
> supporting generic extension or restriction of search/retrieval of
> information resources. A "Seyfert Galaxies" concept in SKOS would be
> intended to index/retrieve information resource about Seyfert galaxies
> in general, or a specific one (e.g., any image, data, theoretical
> articles). It could be represented in the same hierarchical scheme as
> "Cosmology", such as :
> Cosmology > Galaxies > Active Galaxies > Seyfert Galaxies
> Note the plural, whereas if I want to set an ontology to classsify
> individual objects, I will maybe come up with the class-subclass tree
> Galaxy > Active Galaxy > Seyfert Galaxy
> With e.g ESO 97-G13 being an instance of the latter, and inheriting the
> upper classes. A Seyfert Galaxy is a Galaxy
> It's clear than putting "Cosmology" at the top of the class hierarchy
> would not make sense.
> 
> Generally speaking, every semantic environnement should come up
> eventually with the two kinds of representations, which are both useful
> and can coexist peacefully. More below.
> >
> > It would seem that a solution to the b/n conflict would be to allow a
> > concept to belong to more than one broader concept, but this is not,
> > AFAIK, possible in SKOS.
> >
> Oh, yes it is. SKOS allows multiple broader for one concept, and many
> thesauri use multiple broader. There are issues to consider when
> setting
> multiple hierarchies, both interfaces issues and use for queries. It's
> easy to expand a 1-n tree downwards, trickier when it's multiple
> onward.
> See e.g. how multihierarchy is handled in the Web interface of the
> Medical Vocabulary MeSH
> http://www.nlm.nih.gov/cgi/mesh/2007/MB_cgi?&term=Lung+Neoplasms
> (sorry for the example - less attractive than Seyfert Galaxies)
> >
> > I suspect we have to choose one of the following options:
> >
> > 1. Accept that we must have many-to-many b/n relationships and so
> > cannot use SKOS to record the IVOA vocabularies: use some sort of
> > ontology format (OWL?).
> >
> Those issues are orthogonal. You don't represent the same kind of
> hierarchies, and you don't support the same tasks, in OWL and in SKOS
> (see above) and that has nothing to do with dealing with multiple
> hierarchies or not, and not even with more or less expressivity of one
> language vs the other. They have simply not the same objectives.
> >
> > 2. Accept the above but use SKOS to record the concepts and decide
> > (majority vote?) to place each concept under the parent concept
> people
> > would be most likely to search on.
> >
> There are different solutions to handle multiple hierarchies, one being
> to qualify ("color") the b/n links so that the multi-hierarchical graph
> is considered as the entangling of distinct graphs, in each of one
> there
> is no multiple hierarchy. The RDF notion of "named graph" allows to do
> that. In the above example "Seyfert Galaxies" concept could belong to
> another concept scheme, e.g. of spectral type, like:
> X-ray sources > Active Galactic Nuclei > Seyfert galaxies
> >
> > [2a. Perhaps as a parallel activity (if someone wants to undertake
> > it), an ontology is created whereby each term in the ontology is the
> > URI of each SKOS concept and all the relationships are recorded. This
> > would enable both simple (SKOS-based) and complex (ontology-based)
> > search engines to be trialled.]
> >
> Don't do that! At least don't do it this way. If you go the RDF way,
> please keep distinct the URI for the SKOS concept and the URI for the
> equivalent/similar/matching OWL class, so that you can identify very
> distinctly, e.g.,
> 
> <http://www.ivoa.net/voc/thesaurus/Seyfert_Galaxies> rdf:type
> skos:Concept
> <http://www.ivoa.net/voc/onto/Seyfert_Galaxy> rdf:type owl:Class
> 
> The former being used for indexing, search and retrieval of documents,
> the latter for classification of instances.
> There are several ways to link them afterwards, such as the following
> (fictive URIs, of course)
> 
> <http://en.wikipedia.org/wiki/Circinus_Galaxy> skos:subject
> <http://www.ivoa.net/voc/thesaurus/Seyfert_Galaxies>
> <http://en.wikipedia.org/wiki/Circinus_Galaxy> foaf:primaryTopic
> <http://www.ivoa.net/catalog/ESO/97-G13>
> <http://www.ivoa.net/catalog/ESO/97-G13> rdf:type
> <http://www.ivoa.net/voc/onto/Seyfert_Galaxy>
> 
> The first triple allows to find the information resource indexed on a
> subject (to use by a search engine), the second to find a specific
> individual object about which this resource gives information, and the
> third one the logical type of this individual (to use by a reasoner).
> 
> Note that those three statements are completely independent and feed
> different tools and have different objectives.
> 
> It's been heavily discussed among Semantic Web gurus if the above
> skos:Concept and owl:Class should be linked, and if yes, how, but this
> leads to subtle problems I won't try to explain here, and there's no
> standard answer. In applications we develop for Mondeca customers, we
> have come to the conclusion that keeping classes and descriptors
> independent is generally a clean solution. They are indirectly linked
> by
> individual resources.
> >
> > 3. Accept that it would take too long to agree on which type to use
> > for each b/n relationship and only define the concepts in the
> > SKOS-based IVOA vocabulary.
> >
> Setting a SKOS structure is simpler than setting an ontology. It has
> not
> the same objectives.
> >
> > Comments?
> >
> You got some :-)
> 
> Bernard
> 
> --
> 
> *Bernard Vatant
> *Knowledge Engineering
> ----------------------------------------------------
> *Mondeca**
> *3, cité Nollez 75018 Paris France
> Web: www.mondeca.com <http://www.mondeca.com>
> ----------------------------------------------------
> Tel: +33 (0) 871 488 459
> Mail: bernard.vatant at mondeca.com <mailto:bernard.vatant at mondeca.com>
> Blog: Leçons de Choses <http://mondeca.wordpress.com/>
>