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

Hi Vladimir!

10.04.2014 15:42, Vladimir Alexiev wrote:
>> So broaderInstantial is a sort of weaker form of rdf:type.
> Yes, sort of.
> Consider this example from GND:
>    <http://d-nb.info/gnd/5055902-3> gnd:broaderTermInstantial <http://d-nb.info/gnd/4155742-6> .
>    # "Dynamo Dresden football club" BTI "Football"
> Dynamo is not an instance of Football (it's an instance of Football Club).
> But the semantic intent is right, so if they don't have Football Club as a concept, I wouldn’t criticize GND for this case.

Thanks, this is an excellent example. I think it clarifies BTI a bit - 
"X BTI Y" doesn't mean "X is an instance of Y" (like rdf:type would 
say), but something along the lines of "X is an instance of *something* 
while Y isn't, and X belongs under Y in the hierarchy". Right?

> - More importantly, these combinations (BTG-BTG=BTGT and BTP-BTP=BTPT) are not sufficient.
> -- BTG-BTP=BTPT and BTP-BTG=BTPT are also needed:
>     ailerons BTP airplanes BTG air/space vehicles => ailerons BTPT air/space vehicles
>     beak irons BTG anvil components BTP anvils and anvil accessories => beak irons BTPT anvils and anvil accessories
> -- BTI-BTG=BTIG is also justified:
>     Akropolis BTI Greek religious center BTG Religious center => Akropolis BTIT Religious center
> -- And maybe some more combinations (we'll explore them all as part of Getty TGN mapping)

It's a good thing you explore these. I hope it leads to more insight for 
everyone.

> - I just discovered that the FinnONTO SKOS Extensions (http://www.ldf.fi/schema/skosext/)
>    by Osma Suominen (Aalto University), 11 May 2011
>    has similar things: broaderGenericTransitive, broaderPartitiveTransitive.
>    Great minds think alike (ahem :-)

Heh :)

Since you brought that up - the reason for defining that set of 
properties was that at the time, we (in the SeCo research group) wanted 
to express the Finnish General Ontology YSO and some other related 
vocabularies that had thus far been represented as (thesaurus-like) OWL 
ontologies, using SKOS. But there were relationships we had in there, 
particularly part-of, that SKOS didn't include. The SKOS Extensions 
draft [1] looked promising at first, but it had in practice been 
abandoned by the SKOS working group (for good reasons). Since we wanted 
to use the same kind of properties, we coined our own URIs for basically 
the same properties and used those. broaderGenericTransitive and 
broaderPartitiveTransitive were added for completeness, but never used 
for anything in practice. So I can't really take much credit for 
thinking deeply about transitivity.

..that is, until we discovered that we didn't really want to model our 
part-of relationship as broaderPartitive (and broaderGeneric for the 
is-a relationship), because it messes up the skos:broader hierarchy 
pretty badly after inference. So later on we started using just a simple 
partOf relationship that was not a subproperty of skos:broader. Then we 
could use plain skos:broader for the is-a relationship, which made life 
much simpler. (The original SKOS Extensions draft also includes 
relatedPartOf, which in hindsight would perhaps have been more 
appropriate...)

>> 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.
>
> Disagree. Materialized derived properties will always be faster.

Agree to disagree then. In my mind, efficiency of querying is not a 
sufficient reason for introducing new elements into the data model. You 
could always do optimizations like this locally (or some other kind of 
indexing, because that's what it is), but I don't like having 
broaderTransitive in the SKOS spec (especially as it seems to confuse 
people a lot, as mentioned in recent discussions on this list).

Some people also assert skos:broaderTransitive relations directly, 
instead of using skos:broader and letting inference handle the rest, 
apparently because it sounds like it's a stronger statement than 
skos:broader though it's actually the other way around. IPTC and UMBEL 
are two examples where this happens, as discovered in our study on SKOS 
quality [2].

> iso-thes defines BTG, BTI, BTP. I think it better also define their composability.

I think iso-thes already takes the world of SKOS many steps ahead. 
Aspects such as this can also be left for further work.

>> 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
>
> Place types *are* AAT Concepts. Representing them redundantly as ConceptGroups seems like a bad idea.

In my mind, something being a skos:Concept (or aat:Concept or whatever) 
is quite distinct from that thing being a type of place, so it wouldn't 
be wrong to have separate instances of these. At the very least, I would 
somehow declare the subset of AAT Concepts that are considered valid 
place types, perhaps having the same instances being both skos:Concepts and

> And what would be that "suitable link"?

I thought of something like foaf:focus, but I'm not really sure.

>> This way you avoid asserting broader relationships between TGN and AAT,
>
> But what's wrong with spanning from TGN to AAT?
> skos:broaderMatch<skos:broader does that,
> so why can't gvp:placeType<gvp:broaderInstantial do it too?
>
>> and use a standard way of representing the place types without messing up the hierarchies.
>
> - I don’t believe a use case of iso:ConceptGroup for this purpose is defined in the standard (though I don't have it).
>    iso:ConceptGroup is an ad-hoc grouping... I'm not sure considering the "Group of all inhabited places" is useful.
> - Furthermore, transitivity of iso:ConceptGroup membership (skos:member) is not considered.
>    But it's needed for placeType (see the Akropolis example above)

OK. I sort of guessed you wouldn't accept my suggestion, but I wanted to 
hear your arguments anyway :) I've been recently using 
isothes:ConceptGroups for some groupings of concepts and want to 
understand what it's good for and what not. It doesn't fit this use case 
very well, it's better suited for thematic grouping of concepts (e.g. 
"Forestry related concepts") that are not expressed in the hierarchy.

After this discussion, I think I can agree that using broaderInstantial 
(or perhaps a more specific sub-property thereof, with proper domain and 
range declarations declaring its intended usage pattern) would be an 
appropriate way to link TGN places to AAT place types.

-Osma


[1] http://www.w3.org/2004/02/skos/extensions/spec/2004-10-18.html

[2] Osma Suominen and Christian Mader: Assessing and Improving the 
Quality of SKOS Vocabularies. Journal on Data Semantics, 2013.
Preprint at 
http://www.seco.tkk.fi/publications/2013/suominen-mader-skosquality.pdf


-- 
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 Thursday, 10 April 2014 17:30:17 UTC