Updated NeoGeo Spec

22 views
Skip to first unread message

Andreas Harth

unread,
Feb 6, 2012, 8:39:38 AM2/6/12
to neogeo-semant...@googlegroups.com
Hi,

we've published a "Madrid Edition" of the NeoGeo vocabulary
specification [1]. We think it's ready for deployment, and
already have some datasets published using NeoGeo.

Have a look and let us know what you think!

Best regards,
Andreas.

[1] http://geovocab.org/doc/neogeo/

Werner Kuhn

unread,
Feb 6, 2012, 11:28:03 AM2/6/12
to neogeo-semant...@googlegroups.com
Nice work! I will be interested to see reasoning applications on the datasets.

As a minor point: you may want to replace the word "connected" with something like "related" in the following sentence, to avoid confusion with the connected predicate: 
"The following example illustrates the modelling distinction between Feature and Geometry.. :Karlsruhe is a spatial:Feature, and connected to http://example.org/geo/kageo, which is a geom:Geometry."

cheers,
Werner

-- 
Werner Kuhn
Sent with Sparrow

gberg...@gmail.com

unread,
Feb 6, 2012, 8:42:40 PM2/6/12
to neogeo-semant...@googlegroups.com
It is indeed a wonderful connection of the 2 Vocamps to have this assertion relating Feature and Geometry which also came up in our discussion of Path.

Gary Berg-Cross
Sent from my Verizon Wireless BlackBerry

From: Werner Kuhn <werne...@gmail.com>
Date: Mon, 6 Feb 2012 17:28:03 +0100
Subject: Re: [neogeo-semantic-web-vocabs] Updated NeoGeo Spec

Andreas Harth

unread,
Feb 7, 2012, 4:37:55 AM2/7/12
to neogeo-semant...@googlegroups.com
Hi,

On 06/02/12 17:28, Werner Kuhn wrote:
> Nice work! I will be interested to see reasoning applications on the
> datasets.
>
> As a minor point: you may want to replace the word "connected" with
> something like "related" in the following sentence, to avoid
> confusion with the connected predicate: "The following example
> illustrates the modelling distinction between Feature and Geometry..
> |:Karlsruhe|is a spatial:Feature, and connected to

> |http://example.org/geo/kageo|, which is a geom:Geometry."

thanks Werner! We've updated the text accordingly.

Re reasoning applications, I'd be also interested in seeing people
use the datasets based on NeoGeo and do experiments. Hope that'll
happen in the next few years.

Cheers,
Andreas.

Claus Stadler

unread,
Feb 8, 2012, 5:07:11 PM2/8/12
to neogeo-semant...@googlegroups.com
Hi,

http://geovocab.org/geometry.html

defines <http://geovocab.org/geometry#geometry>
however, there is no inverse property for it.
This means that in the case of Linked Data interfaces that only show the "outgoing edges" of a requested resource,
geovocab does not provide a property for linking back to the resource(s) the requested resource is a geometry of.

I suggest introducing an inverse property of http://geovocab.org/geometry#geometry such as
http://geovocab.org/geometry#isGeometryOf

Andreas already hinted that he is fine with an inverse property, but he does not like the naming ;)

An alternative name could be either
. http://geovocab.org/geometry#feature
. http://geovocab.org/spatial#feature

But then we would force the domain of geom:geometry to be spatial:Feature, and we would have a cross-dependency between the geom and spatial namespace.

So I would suggest the neutral geom:isGeometryOf as the name.

Any opinions?

Cheers,
Claus

boricles

unread,
Feb 9, 2012, 8:09:58 AM2/9/12
to neogeo-semant...@googlegroups.com
Hi Claus

Very good question .... ;)

I think "geom:isGeometryOf" is ok, as first option.

Boris

Andreas Harth

unread,
Feb 9, 2012, 11:45:15 AM2/9/12
to neogeo-semant...@googlegroups.com
Hi guys,

in general, yes, I like the idea of having an inverse (although there
are arguments against inverse properties [1]).

Following the naming schemes in RDFS and OWL (owl:inverseOf,
rdfs:subPropertyOf...), I'd suggest to drop the "is", and go simply
with "geom:geometryOf".

Would that be ok?

Regarding cross-dependency: we could (should?) make spatial:Feature
the domain of geom:geometry, and the range of geom:geometryOf. Any
objections there?

Cheers,
Andreas.

[1]
http://richard.cyganiak.de/blog/2006/06/an-rdf-design-pattern-inverse-property-labels/

On 02/09/12 14:09, boricles wrote:
> Hi Claus
>
> Very good question .... ;)
>
> I think "geom:isGeometryOf" is ok, as first option.
>
> Boris
> On Wed, Feb 8, 2012 at 11:07 PM, Claus Stadler
> <ravena...@googlemail.com <mailto:ravena...@googlemail.com>> wrote:
>
> Hi,
>
> http://geovocab.org/geometry.html
>
> defines <http://geovocab.org/geometry#geometry>
> however, there is no inverse property for it.
> This means that in the case of Linked Data interfaces that only show
> the "outgoing edges" of a requested resource,
> geovocab does not provide a property for linking back to the
> resource(s) the requested resource is a geometry of.
>
> I suggest introducing an inverse property of
> http://geovocab.org/geometry#geometry such as
> http://geovocab.org/geometry#isGeometryOf

> <http://geovocab.org/geometry#geometry>


>
> Andreas already hinted that he is fine with an inverse property, but
> he does not like the naming ;)
>
> An alternative name could be either
> . http://geovocab.org/geometry#feature

> <http://geovocab.org/geometry#geometry>
> . http://geovocab.org/spatial#feature
> <http://geovocab.org/spatial#Feature>

Werner Kuhn

unread,
Feb 9, 2012, 6:01:19 AM2/9/12
to neogeo-semant...@googlegroups.com, Krzysztof Janowicz
Dear Andreas and all,

what arguments do we have to "clutter" a vocabulary with inverses, given the arguments in [1]?

cheers
werner

Claus Stadler

unread,
Feb 10, 2012, 10:02:09 AM2/10/12
to neogeo-semant...@googlegroups.com
Hi all,

I now agree that rather than having a vocabulary of inverses, it is better to just provide an appropriate (sub-) set of ingoing-links in the Linked Data interface of a requested resource.


>> Regarding cross-dependency: we could (should?) make spatial:Feature the domain of geom:geometry, and the range of geom:geometryOf. Any objections there?

Right now I neither see harm in specifying the domain nor in leaving it out. In this sense, I currently have no objection for making spatial:Feature the domain of geom:geometry.


Cheers,
Claus

Ghislain Atemezing

unread,
Feb 10, 2012, 12:33:20 PM2/10/12
to neogeo-semant...@googlegroups.com
Hi all, 

2012/2/9 Andreas Harth <ha...@kit.edu>

Hi guys,

in general, yes, I like the idea of having an inverse (although there
are arguments against inverse properties [1]).

Thanks for the post! But I rather prefer to have inverse properties for each property declared in a vocabulary. 
 
Following the naming schemes in RDFS and OWL (owl:inverseOf,
rdfs:subPropertyOf...), I'd suggest to drop the "is", and go simply
with "geom:geometryOf".

Would that be ok?

Ok., using geom:geometryOf is consistent with names for the properties. 
And talking about consistency, why do we use for the functions C, DC, etc, like here http://geovocab.org/spatial.html#C
Where there because they define functions? (It is just for curiosity)
 
Regarding cross-dependency: we could (should?) make spatial:Feature
the domain of geom:geometry, and the range of geom:geometryOf.  Any
objections there?

For me it is OK. 

Cheers,
Ghislain



--

http://www.eurecom.fr/~atemezin/

Andreas Harth

unread,
Feb 10, 2012, 1:00:38 PM2/10/12
to neogeo-semant...@googlegroups.com
Hi,

On 02/09/12 12:01, Werner Kuhn wrote:
> what arguments do we have to "clutter" a vocabulary with inverses, given
> the arguments in [1]?

the issue is that while you can traverse from a Feature (e.g., [1]) to
a Geometry (e.g., [2]), it's not possible to traverse the inverse
direction, if you assume that Linked Data lookups return all triples
with the dereferenced URI as subject.

A fix would be that [2] also returns a triple

<http://test.linkedgeodata.org/triplify/node29857233> geom:geometry
<http://test.linkedgeodata.org/geometry/node29857233> .

so that Linked Data agents can traverse back to the Feature.

The alternative fix would be to have an inverse of geom:geometry
(i.e., geom:geometryOf). FOAF, a very popular vocabulary, took
that pragmatic decision.

The first option is doing it the completely right way (tm), and
the second option is the pragmatic route.

I'm fine with both, possibly adding a geom:geometryOf as an unstable
term and seeing how people use that.

Best regards,
Andreas.

[1] http://test.linkedgeodata.org/triplify/node29857233
[2] http://test.linkedgeodata.org/geometry/node29857233

Boris Villazon-Terrazas

unread,
Feb 13, 2012, 2:06:25 PM2/13/12
to neogeo-semant...@googlegroups.com
Hi Andreas, all

On Feb 10, 2012, at 7:00 PM, Andreas Harth wrote:

> Hi,
>
> On 02/09/12 12:01, Werner Kuhn wrote:
>> what arguments do we have to "clutter" a vocabulary with inverses, given
>> the arguments in [1]?
>
> the issue is that while you can traverse from a Feature (e.g., [1]) to
> a Geometry (e.g., [2]), it's not possible to traverse the inverse
> direction, if you assume that Linked Data lookups return all triples
> with the dereferenced URI as subject.
>
> A fix would be that [2] also returns a triple
>
> <http://test.linkedgeodata.org/triplify/node29857233> geom:geometry <http://test.linkedgeodata.org/geometry/node29857233> .
>
> so that Linked Data agents can traverse back to the Feature.
>
> The alternative fix would be to have an inverse of geom:geometry
> (i.e., geom:geometryOf). FOAF, a very popular vocabulary, took
> that pragmatic decision.
>
> The first option is doing it the completely right way (tm), and
> the second option is the pragmatic route.
>
> I'm fine with both, possibly adding a geom:geometryOf as an unstable
> term and seeing how people use that.
>

Yes, I think we can add a geom:geometryOf as an unstable term.

Thanks for your work again.

Boris

Reply all
Reply to author
Forward
0 new messages