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

+1 for Christophe's solution.

This is a solution we have adopted in Mondeca for about ten years in many
configurations and various domain where you want to maintain both a sound
knowledge base of "real-world things", and a SKOS image of this knowledge
"simplified" for faceted classification, search-and retrieval, whatever
applications consuming SKOS-based schemas. And indeed, transformations
based on SPARQL CONSTRUCT are key.
It has proven a scalable and flexible approach, much more than twisting the
SKOS model to represent "things" it was not designed to represent.
For the specific question of place types, in Geonames ontology they are
represented as independent Concept Schemes (rather flat, but some hierarchy
could be added), the places themselves being linked to this scheme by the
dedicated pointer geonames:featureCode, defined as a subproperty of
dctems:type.
Places themselves (geonames:Feature) are not represented as skos concepts
in geonames ontology, but in many case I've used a SKOS representation of
the administrative hierarchy (country > ADM1 > ADM2 > ADM3 > ADM4) turned
into a simple SKOS "view" of this hierarchy.
In such a configuration you get a hierarchy of "place-concepts" with an
orthogonal facet of "type-concepts", both in SKOS, and it works nicely for
faceted classification.

The more I use SKOS, the more I see it that way : a translation of
knowledge fit for a certain type of application. Everything (every thing)
can be re-presented as a skos:Concept for some purpose, but nothing is a
skos:Concept *in essentia*.




2014-03-30 10:15 GMT+02:00 Christophe Dupriez <dupriez@destin.be>:

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


-- 

*Bernard Vatant*
Vocabularies & Data Engineering
Tel :  + 33 (0)9 71 48 84 59
Skype : bernard.vatant
http://google.com/+BernardVatant
--------------------------------------------------------
*Mondeca*
35 boulevard de Strasbourg 75010 Paris
www.mondeca.com
Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>
----------------------------------------------------------