Updated NeoGeo Spec

[Andreas Harth]

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]

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]

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>

Sender: neogeo-semant...@googlegroups.com

Date: Mon, 6 Feb 2012 17:28:03 +0100

To: <neogeo-semant...@googlegroups.com>

ReplyTo: neogeo-semant...@googlegroups.com

Subject: Re: [neogeo-semantic-web-vocabs] Updated NeoGeo Spec

[Andreas Harth]

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]

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]

Hi Claus

Very good question .... ;)

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

Boris

[Andreas Harth]

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]

Dear Andreas and all,

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

cheers

werner

[Claus Stadler]

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]

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]

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]

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