Re: Some comments on the spatial ontology (sdwgeo)

Hi
Over October I have the opportunity to set up facilities at OGC to serve
these - including SPARQL endpoints, Linked Data views etc. I'll be doing
this for QB4ST and importing the ontology anyway, and using SPIN rules to
generate user-friendly views of different entailments (if that is the
correct terminology). Maybe next week I can demonstrate the plan.  The
policy decision to make these persistent will need to be made by the OGC -
but its a general issue the OGC is facing anyway with its definition
services.

What would help there is a succinct statement of requirements (i would
suggest: what namespace, stability, at least HTML, SKOS  and OWL views of
definitions, "developer friendly" API to access ontologies managed in
sensible small modules but accessible as complete ontologies, and
expression of SDW BP )) from the SDW group.

Cheers
Rob


On Tue, 27 Sep 2016 at 21:21 Joshua Lieberman <jlieberman@tumblingwalls.com>
wrote:

> The ontology is available from geosemweb.org/sdwgeo, but I will see this
> week about getting it on to Github to work with.
>
> Josh
>
> On Sep 27, 2016, at 06:28, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>
> Hi Josh,
>
> Yes, I am guilty of bringing up many subjects at once. There should be a
> better practice. I noticed finding a balance in how to discuss issues is a
> challenge in the development of the SSN ontology too. Using GitHub to
> discuss particular bits of the ontology is convenient, but lacks exposure.
> I have understood that the SSN team will attempt to discuss (important)
> decisions on the general e-mail list, so everything is exposed and recorded
> for eternity.
>
> Does the current spatial ontology live in a place like Github, where it is
> possible for people to discuss minor details or suggest particular changes?
> Also I wonder if the ontology is available online, so any examples put on
> the wiki can have proper links to vocabulary terms.
>
> Regards,
> Frans
>
>
>
> On 26 September 2016 at 15:05, Joshua Lieberman <
> jlieberman@tumblingwalls.com> wrote:
>
>> Frans,
>>
>> The scenario we've discussed is SDW being able to cite an OGC standard
>> spatial ontology as a best practice. To process a standard, OGC needs to
>> form a standards working group. It doesn't mean, however, that only OGC
>> members work on the ontology or provide feedback to it. We hope that it can
>> be a cooperative and publicly visible effort with everyone on the SDWWG.
>>
>> I agree about the interleaved email complexity,  but you did start about
>> a dozen discussion threads at once here! We should pick out the most
>> significant ones, I guess, and move them to the wiki.
>>
>> On Sep 26, 2016, at 07:28, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>>
>> Hello Josh,
>>
>> Yes, I now remember the idea of forming an OGC group to work on sdwgeo.
>> How soon could that group be formed?
>>
>> The OGC of course is a great place to find the necessary expertise.
>> However, a risk of an OGC-only group could be that the ontology will turn
>> out to be a geospatial ontology, not a spatial ontology, and that it does
>> not meet the requirements of general web developers, for example. I liked
>> the idea of the development of the spatial ontology taking place in the
>> SDWWG for that reason. Also it would probably be beneficial to have
>> exposure to web communities from the start.
>>
>> I understand you giving up on WebProtégé. It was very hard for me to
>> understand the ontology by just using WebProtégé. It is probably better to
>> develop the ontology as a shared raw file that people can load into their
>> editor or viewer of choice. So the  WebProtégé ontology is no longer the
>> current version? I followed the link to the ontology in development on
>> the wiki
>> <https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL#Ontology_in_development>.
>> Can we replace that link?
>>
>> Further replies are inline below. But it seems this way of addressing
>> multiple issues in the same e-mail message gets messy very quickly.
>>
>> On 23 September 2016 at 21:41, Joshua Lieberman <
>> jlieberman@tumblingwalls.com> wrote:
>>
>>> Hi Frans,
>>>
>>> We’ve agreed, I think, to get a group at OGC working on sdwgeo as soon
>>> as possible, so visibility is good and will be improving. I’ve given up on
>>> WebProtege as there is really no way to version ontologies within it even
>>> when one bothers to reach a particular project.
>>>
>>> Responses below:
>>>
>>> On Sep 23, 2016, at 10:13 AM, Frans Knibbe <frans.knibbe@geodan.nl>
>>> wrote:
>>>
>>> Hello Josh,
>>>
>>> Many times during the F2F meeting in Lisbon the idea that work on an
>>> agreed spatial ontology is very important was confirmed for me. So I had a
>>> look at the ontology in WebProtégé
>>> <http://webprotege.stanford.edu/#Edit:projectId=fa09f9df-1078-4c17-a16c-ae83695ff431>
>>> in its current state. You wrote that comments are welcome. I thought a
>>> message like this would be the best way to share such comments,
>>> although WebProtégé has its own comment system - it could be that comments
>>> in WebProtégé go unnoticed and besides that all decision making should be
>>> publicly recorded for eternity.
>>>
>>> So below are some comments and questions. Please excuse me for any
>>> stupid comments, I am not an ontologist and there are probably a lot of
>>> things I misunderstand.
>>>
>>> And I hope that more people can find the time to look at this crucial
>>> piece of work.
>>>
>>>    1. Most importantly: Thank you for setting up the ontology!
>>>    2. Earlier I asked about starting with the GeoSPARQL ontology and
>>>    work from there. You answered that is not practical because WebProtégé does
>>>    not seem to support refactoring. Still, it seems to me that the base
>>>    classes and properties defined in GeoSPARQL 1.0.1 (gspql:geometry,
>>>    gspql:SpatialObject and gspql:Feature) should be in the new ontology
>>>    somewhere, if only for ensuring backward compatibility.
>>>
>>> The two basic entities are in there: Feature and Geometry. I removed
>>> SpatialThing as the superclass of both in order to enforce the distinction
>>> between recognizing a spatial thing and modeling it. So, SpatialThing is
>>> set equivalent to Feature and Geometry is one possible form of
>>> SpatialModel. I then moved many of the GeoSPARQL classes and entities into
>>> new positions in sdwgeo following this structure.
>>>
>>
>> Yes, that would be an improvement. But I notice gspql:SpatialObject is
>> now absent from the ontology. Wouldn't that cause a backward compatibility
>> issue? Or can it be assumed that gspql:SpatialObject is used nowhere?
>>
>>
>> I doubt that anyone used it explicitly.
>>
>>
>>>    1. I wondered if topology should be included in the ontology (see my
>>>    earlier message to the list
>>>    <https://lists.w3.org/Archives/Public/public-sdw-wg/2016Sep/0190.html>),
>>>    but I noticed it's already in there (in the TopoModel class). I am happy to
>>>    see that.
>>>
>>> There is a somewhat different approach between this and ISO19109 / OGC
>>> AS 5. While SpatialThing and Geometry are disjoint, a SpatialThing can also
>>> be a topological element. All an element does is allow topological
>>> relationships and it’s much more intuitive to define those relationships
>>> between the actual SpatialThing entities.
>>>
>>>
>>>    1. SpatialThing is an important class, but its definition is not
>>>    clear. It refers to ISO 19109, but that definition is not something
>>>    everyone can look up. How about definitions like "Something that has some
>>>    kind of spatial presence", or the current definition in the BP document,
>>>    taken from the Basic Geo vocabulary: "Anything with spatial extent, i.e.
>>>    size, shape, or position. e.g. people, places, bowling balls, as well as
>>>    abstract regions like cubes.”
>>>
>>> The business model of charging for ISO specs unfortunate, to put it
>>> mildly. However, ISO 19109 is equivalent to OGC Abstract Topic 5 (
>>> http://portal.opengeospatial.org/files/?artifact_id=29536) which is
>>> freely available. So now you can read all about the General Feature Model.
>>>
>>>
>>>    1. Continuing the point above, can SpatialThing be defined as some
>>>    sort of equivalent of geo:SpatialThing?
>>>
>>> The latter includes both entities in the real world and models for them,
>>> so they are similar but not equivalent (some entities included in
>>> geo:SpatialThing are not in sdwgeo:SpatialThing)
>>>
>>
>> It seems to me that the definition of geo:SpatialThing is rather loose.
>> Does it explicitly include models of spatial things, or try to discern
>> between real world things or models of them? Tying a OGC based ontology
>> like GeoSPARQL to common web ontologies seems like a very important step
>> towards a truly domain-independent information model, so really trying to
>> find or create common ground seems like a worthwhile effort.
>>
>>
>> The definition of SpatialThing in W3C geo was quite loose. In sdwgeo, the
>> definition is tightened up to align with the general feature model and
>> exclude spatial models, which are really mathematical things.
>>
>>
>> [snip]
>>
>>>
>>>    1. In Lisbon we had some discussion about the computability of
>>>    spatial relationships, specifically topological relationships. In my view,
>>>    both SpatialThings and Geometries can have spatial relationships. In the
>>>    first case, they can be used as assertions, in the second case they are
>>>    computable. I
>>>
>>> Agreed
>>>
>>>
>>>    1. f this view makes sense, is it useful to define two sets of
>>>    spatialRelations, one for spatial things and one for geometries?
>>>
>>> I don’t know that we need to do that. We want to be able infer
>>> relationships between features from relationships between geometries and
>>> even mixtures of features and geometries.
>>>
>>
>> But we also want to be able to make statements about spatial
>> relationships between things even if no geometry is available, don't we?
>>
>>
>> Yes, although some relationships can only be computed from geometries.
>>
>>
>>
>>>
>>>    1. Another suggestion made in Lisbon: could we regard the
>>>    spatialRelation 'equals' as meeting the requirement to express
>>>    subject equality
>>>    <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SubjectEquality>
>>>    ?.
>>>
>>> The spatial relation just says that each geometry is made up of the same
>>> set of points. Not sure that spatial equality should be the same as subject
>>> equality.
>>>
>>
>> This suggestion was based on te premise that there are two kinds of
>> spatial relationships: one set for spatial things (not computable) and one
>> set for geometries (computable). The idea was that the 'equals' property of
>> the former set could play that role.
>>
>> [snip]
>>
>>>
>>>    1. Is there an entity in the ontology that can be used for
>>>    expressing the array of coordinates that can be used to define a geometry?
>>>
>>> No, it is only a dependent property, for the reason that it is
>>> meaningless without definition of the geometry.
>>>
>>
>> I am not sure what that means exactly, one reason why I'd love to see
>> some examples of how the ontology could be used. Does it mean one always
>> has to use the WKT, GML or JSON literals to express the coordinates?
>>
>>>
>>>
>>>    1. I find it quite hard to see how the parts of the ontology are
>>>    related. I think understanding the use of the ontology would be helped a
>>>    lot with some examples (resource descriptions in RDF). I would like to try
>>>    to make some examples, but what would be a good place for that? A new wiki
>>>    page? Or is it better to start with a proper HTML document in GitHub that
>>>    explains how to use the ontology, something that can be turned into a more
>>>    or less official document?
>>>
>>> Examples would be good, and would presumably be moved into part of an
>>> OGC spec document. Wiki for now?
>>>
>>
>> It would make an easy start. I would not mind trying to make a new wiki
>> page with some examples once I am sure of the location of the current
>> ontology.
>>
>>>
>>>
>>>    1. Can other people edit the ontology? Perhaps others can contribute
>>>    resource descriptions (labels and comments in different languages).
>>>
>>> It needs some modularization anyway. Could see about working with it on
>>> GitHub to support shared work and versioning. I’ll experiment…may have to
>>> go in gh-pages so that each module can be imported to another.
>>>
>>
>> In this respect it is interesting to witness the discussion on
>> modularization in SSN. It seems there might be less benefits of
>> modularization there than initially thought. But if there are clear borders
>> in the spatial ontology, perhaps it would help collaboration on the
>> ontology, with different groups of people being responsible for different
>> modules. Simplicity for end users is mostly helped by good documentation
>> and good examples, I think.
>>
>>
>>>
>>>    1. Why is LinearReference a separate class? Isn't it the same as a
>>>    2D CRS?
>>>
>>> A linear reference system is different from a CRS. A CRS has global
>>> reference geometries, while a linear reference involves identifying
>>> specific linear and point features (in their own CRS’s) as the reference
>>> for a linear measure. Covered exhaustively and obscurely in ISO 19148. It
>>> will need separate explanation, for sure.
>>>
>>
>> Does a CRS have to be global? I hope it will be possible to define a CRS
>> in another solar system, in a building, on a piece of paper, on a  web page
>> canvas or on a microscope slide, for example.
>>
>> If all constructs in the ontology are intended to be spatial instead of
>> geospatial, does linear referencing still require its own set of constructs?
>>
>>
>> [snip]
>>
>>>
>>>    1. Can the ontology be related to the Location Core Vocabulary
>>>    <https://www.w3.org/ns/locn>? That would give the opportunity to
>>>    refer to SpatialThings by address or toponym. For example, could
>>>    dcterms:Location be defined as a equivalent class or subclass of
>>>    SpatialThing?
>>>
>>> That’s a mapping I’m still thinking about.
>>>
>>
>> I hope it will be possible. Those kinds of links will make the ontology
>> very powerful/useful.
>>
>> [snip]
>>
>> Greetings,
>> Frans
>>
>>
>