W3C home > Mailing lists > Public > public-esw-thes@w3.org > April 2014

Re: TGN place types (broader/narrower spanning ConceptSchemes)

From: Osma Suominen <osma.suominen@helsinki.fi>
Date: Sat, 05 Apr 2014 11:38:21 +0300
Message-ID: <533FC0FD.6060102@helsinki.fi>
To: public-esw-thes@w3.org
05.04.2014 02:30, Vladimir Alexiev wrote:
>> But nobody has aswered my question: do you think it's a good idea to represent
>> gvp:placeType as subprop of broaderGeneric, spanning from TGN to AAT?
>
> I'm sorry, I meant "as subprop of gvp:broaderInstantial", as per my document

My personal take: I've never quite understood broaderInstantial. It 
seems to imply that the object of the relationship is a class. But the 
object is (most likely) not an owl:Class/rdfs:Class, but a skos:Concept. 
So broaderInstantial is a sort of weaker form of rdf:type.

I know BTI is used within some thesauri which contain obvious instance 
concepts and I guess using broaderInstantial to represent that in 
SKOS/RDF is OK. But then you lose any remaining meaning (if any!) in 
broaderTransitive, as nicely demonstrated by this example:

> But who can explain why skos:broaderTransitive is not always appropriately transitive?
>
> E.g. iso-thes:broaderPartitive and iso-thes:broaderInstantial should not compose.
> E.g. Sofia is part of Bulgaria; Bulgaria is an instance of Country, but Sofia has no relation to Country whatsoever.

My explanation of this is that broaderTransitive/narrowerTransitive is a 
sort of technical hack that can be used to infer the transitive 
broader/narrower hierarchy - but whether it actually makes sense to do 
so for a particular SKOS dataset is left open. Nowadays there are SPARQL 
1.1 property paths and other ways in RDF toolkits to obtain the 
transitive hierarchy, so broaderTransitive is kind of redundant. It is 
also, unfortunately, confusing, misleading and even dangerous, because 
it seems to imply that there exists some meaning in the transitive 
skos:broader hierarchy, which is not always the case.

Vladimir, how about this solution for TGN/AAT place types:

1. Define the place types (derived from AAT) as isothes:ConceptGroup 
instances in TGN (with some suitable link to the original AAT concepts)
2. Use skos:member to represent the link between place type and place 
instances

This way you avoid asserting broader relationships between TGN and AAT, 
and use a standard way of representing the place types without messing 
up the hierarchies.

-Osma


-- 
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Teollisuuskatu 23)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi
Received on Saturday, 5 April 2014 08:38:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:46:36 UTC