W3C home > Mailing lists > Public > public-xg-geo@w3.org > January 2007

Re: [foaf-dev] FOAF, geonames, and more

From: Benjamin Nowack <bnowack@appmosphere.com>
Date: Mon, 29 Jan 2007 09:07:48 +0100
To: "Alexandre Passant" <alex@passant.org>
Cc: public-xg-geo@w3.org, foaf-dev@lists.foaf-project.org
Message-ID: <PM-GA.20070129090748.4DA9B.1.1D@>

On 28.01.2007 17:46:28, Alexandre Passant wrote:
>Right, but what about using based_near for something that is not a
>spatial thing ?
>The only way to do is to assert this is a Spatial Thing, isn't it ?
I can't think of a non-spatial thing that's based near something 
(unless you use "near" in a temporal sense).

>But since foaf:Organisation is not a subclass of geo84:SpatialThing
>(but foaf:Person is), I have to create an union class with foaf:org +
>geo84:ST to use based_near with this org ?
No, "Descriptive, not prescriptive" means that you don't have to 
pre-define rules before you can use certain RDF terms. The orgs
you'd like to use based_near with are spatial things.


   :org foaf:based_near :x .

you can infer that

   :org a geo:SpatialThing .
   :x a geo:SpatialThing .

The description

   foaf:based_near rdfs:domain geo:SpatialThing .

does not say that only resoures explicitly typed as spatial things are
"allowed" to use foaf:based_near. It's exactly the other way round:
Resources which use foaf:based_near *are* spatial things. Independent
of other types they may have. (In OWL you can construct axioms to
identify/prevent inconsistencies, but not in RDF Schema. The latter 
can only increase the total number of triples, but never reduces them.)

Bottom line: You simply don't use foaf:based_near with resources
[in the subset of foaf:Organization] that aren't spatial things. 


>> hth,
>> benjamin
>> On 26.01.2007 17:07:06, Alexandre Passant wrote:
>> >Hi all,
>> >
>> >I'm currently looking for ways to link things (especially foaf:Agents)
>> >to geonames [1] defined entities (since it provides not only lat/long
>> >info but also useful things as wikipedia entry, neighbour places ...).
>> >
>> >Currently, there's a foaf:based_near property, which links two
>> >geo84:SpatialThing(s)
>> >Since geo:Feature (which is used to define all geonames.org ontology
>> >instances) and foaf:Person are subclasses of SpatialThing, we can link
>> >any foaf:Person to a geonames.org "Feature" as:
>> >
>> >http://apassant.net/foaf.rdf#me foaf:based_near
>> >http://sws.geonames.org/2975249/
>> >
>> >Yet, foaf:Agent itself is not a subclass of geo84:SpatialThing
>> >So, I cannot say that a foaf:Organisation is located in a city.
>> >
>> >One solution could be to subclass not only foaf:Person from
>> >geo84:SpatialThing, but foaf:Agent itself.
>> >
>> >The other idea would be to create a new property as locatedIn (in
>> >geonames or in geo84 ontology, or even new namespace) that will link
>> >any owl:Thing / rdf:Resource (and not only subclasses of SpatialThing)
>> >to a geo84:SpatialThing, and that then can be subclassed:
>> >bornIn
>> >worksIn
>> >establishedIn
>> >...
>> >(could also create the property in an existing namespace, and the
>> >subproperties in another one, as the relationship vocabulary [2])
>> >
>> >Thus, I'll be able to describe the location (and specify which kind,
>> >i.e. workplace, establishement place ...) of any foaf:Agent, but also
>> >other things as a ical:VEvent, to point to the city the event is
>> >located, using any geonames Feature instance.
>> >
>> >(I could have suggest to subclass foaf:based_near, but as the "near"
>> >notion is relative, I'm not sure that's a good idea to create
>> >subproperties from it)
>> >
>> >I'll be happy to get feedback about these ideas.
>> >
>> >Best,
>> >
>> >Alex.
>> >_______________________________________________
>> >foaf-dev mailing list
>> >foaf-dev@lists.foaf-project.org
>> >http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>> >
>> >
Received on Monday, 29 January 2007 08:09:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:43:25 UTC