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

Interesting discussion!

My (a bit) radical opinion on this: SKOS is useful to model 
classifications for human targeted retrieval.
I think it is a language to parameterize classical documentary retrieval 
engines (mainly for query expansion).
Not a language to model ontologically a part of the (real/abstract) world.

In this precise case, I would model whatever is needed using the most 
suitable vocabularies available if any.
And I would add (automatically if possible) SKOS relations to guide the 
documentary retrieval engine.
I.e. I would model without constraints something ontologically "rock 
solid" and then derive a "publishing" structure using SKOS.

In SKOS, for retrieval purpose (derived from a more precise ontology to 
be chosen):
* SKOS concept "Crimea" would be a broader of concepts "Crimea before 
1954", "Crimea since 1954 but before 2014", "Crimea since Russian 
invasion in 2014"
* SKOS concept "Ukraina" would include "Crimea since 1954 but before 
2014" and many other regions
* SKOS concept "Russia" would include "Crimea before 1954" and "Crimea 
since Russian invasion in 2014" (and other regions)
This to reflect the precise places the users wish to retrieve when (s)he 
types "Crimea", "Ukraina" or "Russia"
(I do not especially think that an example based on a current and 
difficult situation is good: I merely continue on the basis of previous 
messages: please excuse me. My thoughts are for innocent people in the 
middle of these conflicts).

So I would not try to add all the modelling data in SKOS: I would rely 
on another ontology for this...

To implement this, I would suggest to use a SPARQL queries to create 
automatically and periodically SKOS graphs starting from ontological 
information served by a (external) SPARQL server. SKOS based 
applications often have a SPARQL or SQL client to extract SKOS graphs 
from non-SKOS data served in RDF, SQL, CSV, XML, etc.

Keep on SKOSing!

Christophe Dupriez
destin-informatique.com
Twitter @ChristopheDupri


Le 30/03/2014 00:26, Richard Light a écrit :
>
> Hi,
>
> I agree with Oreste that we need to model the time dimension.
>
> In your paper, you say early on that
>
> ·Place types have *Historic Info*: Historic flag, Start Date, End 
> Date, and Comment (display date).
>
> Surely that's wrong: the types don't /of themselves/ have these 
> properties; it is only in the context of a specific place (like 
> Machupicchu) that these properties of place types are meaningful.
>
> So, it follows that the relationship between a place and a specified 
> place type can't be a simple "has type" property, linking place and 
> place type. If you do that, there is nowhere to hang these additional 
> place type properties (a classic problem with simplistic RDF).  
> Instead, the relationship could be defined in the context of something 
> like a CIDOC CRM E4 Period ("coherent phenomena or cultural 
> manifestations bounded in time and space"). This E4 Period could have 
> a type meaning "place having type".
>
> Once this aspect is modelled in this way, I don't see how the 
> "broader" relationships between place types impact on the "broader" 
> relationships between the place instances themselves.
>
> Richard
>
> On 29/03/2014 10:30, Oreste Signore wrote:
>> As the leader of the pilot project that led to TGN (yeah, it was 25 
>> years ago) I have something to say about the approach.
>> To my understanding, and this was one of the main issues from the 
>> pilot project, the representation of historical place names (and the 
>> relative falls_within or similar) does not fit well in a theasaurus 
>> structure.
>> At the time, we talked about "database structure" while today we can 
>> talk about "ontologies" ;-) .
>> The relationships are modeling time-dependent features, and:
>>
>> tgn:7018759-concept a skos:Concept;
>>
>> foaf:focus tgn:7018759-place;
>>
>> skos:prefLabel "Sofiya-Grad";
>>
>> gvp:broaderPartitive tgn:7006413-concept; # Bulgaria
>>
>>
>> represent the present status (ignoring anyway any intermediate 
>> administrative level).
>> What about Crimea today or one month ago? (just to recall very recent 
>> events).
>>
>> In other words, we are loosing the "time dimension"
>>
>> I think that perhaps names could be represented taking advantage from 
>> all the well known features of SKOS (just multilingualism support 
>> would be enough), while other aspects should be handled at a richer 
>> and more sophisticated ontological level.
>>
>> To move towards a real LOD environment, we should consider "Changes" 
>> and "Events" which cause changes.
>>
>> If this can help, you can see a recent work on this issues, I'm just 
>> working on a project for historical name places (nice to come back 25 
>> years!)
>> Please find the references:
>> - the paper: 
>> http://www.weblab.isti.cnr.it/papers/public/ch2013-Athens-Signore-paper.pdf
>> - the slides: 
>> http://www.weblab.isti.cnr.it/papers/public/ch2013-Athens-Signore-slides.pdf
>>
>> Best
>> oreste
>>
>>
>> On 28/03/2014 18:48, 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!
>>>
>>
>> -- 
>> dott. Oreste Signore
>> CNR-ISTI
>> cell. +39-348-3962627
>> Skype: orestesignore
>> home page:http://www.weblab.isti.cnr.it/people/oreste/
>
> -- 
> *Richard Light*