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

Hi,

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

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. As Osma mentioned, it is a weaker form of rdf:type, and I think this actually matches pretty well the Getty situation.

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).
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. The others happily won't care; they will probably be instead interested in the benefits of *easily* making the 'powerful queries' in Vladimir's doc.

Cheers,

Antoine

On 3/28/14 6:48 PM, Vladimir Alexiev wrote:
> Hi all!
>
> In preparation for TGN LOD publication, we have an important question:
> how to represent the relation between Place and Place Type.
> Please read the attached document (which is also posed to the GVP external reviewers) and comment here.
>
> Thanks!
>

Received on Saturday, 5 April 2014 18:00:28 UTC