Broader and narrower in Vocab

Tue Sep 18 08:15:42 PDT 2007

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/>