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

[BTP, BTG, BTI]

Osma Suominen:
> 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.

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.

> But then you lose any remaining meaning (if any!) in
> broaderTransitive, as nicely demonstrated by this example:
> > 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's a problem of broaderTransitive, not broaderInstantial.
My feeling about broaderTransitive is the same. A while ago I wrote:
/-----------
iso:broaderGenericTransitive a owl:TransitiveProperty.
  iso:broaderGeneric rdfs:subPropertyOf iso:broaderGenericTransitive.
iso:broaderPartitiveTransitive a owl:TransitiveProperty.
  iso:broaderPartitive rdfs:subPropertyOf iso:broaderPartitiveTransitive.
 
iso:broaderTransitive a owl:ObjectProperty;
  skos:scopeNote """Defined as a disjunction of broaderGenericTransitive and broaderPartitiveTransitive (BTG+BTP).
Unlike skos:broader, this property allows paths of BG and BP but not BI, nor mixed paths of BG+BP.
Despite the name, this property is NOT transitive, because it excludes mixed paths.
To comply with thesaurus design principles regarding query expansion, you should use this property instead of skos:broaderTransitive""".
  iso:broaderGenericTransitive   rdfs:subPropertyOf iso:broaderTransitive.
  iso:broaderPartitiveTransitive rdfs:subPropertyOf iso:broaderTransitive.
\-----------
With the intention that "people in the know" will use this iso:broaderTransitive instead of skos:broaderTransitive.

- Antoine objected about "Despite the name, this property is NOT transitive": 
  so the name is misleading/confusing, and we should pick a different name

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

- 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 :-)

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

----

Johan De Smedt> Sofia broader transitive Bulgaria is not meaningless.

I did not say that. I said Sofia skos:broaderTransitive Country is meaningless.
It makes no sense to compose BTP-BTI.

> I agree it misses more clear semantic details between the linked concept.
> That more semantic expressiveness is to be handled using dedicated ontologies.

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

------------

[Thanks for replying specifically to my question!]

Osma Suominen: 
> 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.
And what would be that "suitable link"?

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

------------

Antoine Isaac:
> if the majority of place types in TGN are currently valid, this extra step in the graph in order to access the proper type will be really a
> burden for the vast majority of data consumers.
> Better use the awkward reification that will only penalize the consumers who are interested in the details

That is indeed the intent. Just like AAT hierarchical relations use reification for Historic info, so will placeType.
This similarity (both having Historic info) was one of the factors that led me to model placeType with broaderInstantial.

> In theory I agree it would be interesting to model the 'place-dependency' of place type links with a (possibly CIDOC-CRM inspired) event.
> (btw the CRM pattern would have the same sort of complexity I believe, so TGN won't be really worse if they use reification).

Indeed. One would use:
- a direct link P2_has_type (shortcut), and
- a reification E17_Type_Assignement (longcut) together with P42_assigned and P41_classified
But note that there's no way to say when a Type stopped being used:
there is E15_Identifier_Assignement.P38_deassigned, but no similar property for E17_Type_Assignement

> About the 'flavour' of the links: I agree with using iso:broaderInstantial (or for that matter, gvp:broaderInstantial) between TGN place and
> AAT place types. 
> I wouldn't be bothered about the risk of "mixing broaderInstantial in TGN". One can still extract the true 'inter-TGN' hierarchical links (or
> the 'external-to-AAT' ones) by adding conditions on the inScheme statements, in the queries for retrieving hierarchical links (I think
> Vladimir has shown one such query).

Thanks!

> I'd have the same lack of worry for multiple preferred parents (in AAT and TGN). The scenarios that really expect uniqueness of
> preferred parents are really ones that are specific to AAT concept management. So it's fair that they would know the data better and can
> express the required constraints if they want 'pure' data.

Agreed: if a user wants only the preferred *place* hierarchy, they should do:
  ?x gvp:narrower tgn:Sofia; skos:inScheme tgn:

-------------

Simon.Cox>
> > do you think it's a good idea to represent gvp:placeType as subprop of broaderGeneric, spanning from TGN to AAT?
> That is counter-intuitive for me. 
> For a particular application, type or class or set is different to instance or individual or member.
> Do you want to use the concept 'Archaeological Site' in the same place that you would use "Acropolis" or "Stonehenge" or "Uluru"?

I added on Sat 4/5/2014 2:30 AM: "sorry, I meant "as subprop of gvp:broaderInstantial", as per my document."
I hope this correction (together with the discussion with Osma above, that broaderInstantial is a weaker form of rdf:type)
addresses your concerns above.

> 'type' usually indicates the class of which something is a member.
> gvp:placeType should be a sub-property of rdf:type.
> If the place-types have been modelled as individuals, then you need to 'pun' them to classes when using them this way.

rdf:type brings a lot of ontological commitment (and baggage) with it.
I think the thesaurus people would explain better than me why skos:broader has no relation to rdf:type and rdfs:subClassOf
But here are a couple of considerations:
- if we do that, surely we should also make every broaderGeneric be rdfs:subClassOf. 
  And for uniformity we need to do it for all AAT concepts, not just place types.
- then what would we do with BTP?

- Getty has a gazillion place types: http://www.getty.edu/vow/TGNPlacePopup
  (where gazillion=754, but an internal table has 1767 types, all these will shortly be converted to AAT concepts).
  Getty will be adding and modifying this extensively, because they want to make the typization richer.
  I doubt people will appreciate an ontology that can change often and unpredictably.
-- I am contradicting myself a bit, since we have modeled AAT associative relations as properties (soon to become subprops of skos:related)

Received on Thursday, 10 April 2014 12:43:25 UTC