- From: Joshua Lieberman <jlieberman@tumblingwalls.com>
- Date: Fri, 23 Sep 2016 15:41:03 -0400
- To: Frans Knibbe <frans.knibbe@geodan.nl>
- Cc: SDW WG Public List <public-sdw-wg@w3.org>
- Message-Id: <7B362D4F-464D-48AF-8256-DB365D311071@tumblingwalls.com>
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. > Most importantly: Thank you for setting up the ontology! > 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. > 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. > 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 <http://portal.opengeospatial.org/files/?artifact_id=29536>) which is freely available. So now you can read all about the General Feature Model. > 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) > I assume the intention of the SpatialModel class is that it can represent a model of a SpatialThing. Shouldn't it say so in its definition/comment? Yes. I shouldn’t assume that any label is a clear definition for everyone. > If Extent is not defined as it usually is understood (an indication of the space a spatial thing occupies), but as a synonym of dimensionality, then why is Extent a subclass of SpatialModel? A SpatialThing may have no intrinsic dimensionality until modeled that way. It’s just a more qualitative model than some. Ask Rob about Catchment if you have some time. The term extent may or may not be used to refer to the minimum bounding box or geometric envelope for a feature, so I’ve re-purposed the term to be more qualitative. Labels! > If Extent is not meant to be used to indicate the space a spatial thing occupies (e.g. a minimal bounding rectangle), then which part of the ontology is meant for that? There is an Envelope geometry and also a geometry property “hasEnvelope" > In a general view of spatial relations there are three types: topological relations (e.g. within, crosses), distance relations (e.g. at, near to, far from) and directional relations (e.g. north of, upstairs from, behind). Would it make sense to define these types as subproperties of spatialRelation, and let the current set of subproperties be subproperties of e.g. topologicalRelation? Unfortunately, ISO 19107 on Spatial Schema is not available as an OGC Abstract Specification, but much of the content is in the freely available GML specification http://www.opengeospatial.org/standards/gml <http://www.opengeospatial.org/standards/gml> which however is very long and XML-specific. Anyway, the topoRelations defined in sdwgeo are the relations between topological elements. They are not the same as spatial topological relationships (touches, disjoint, etc. in RCC8, Egonhofer, Simple Features, and so on) that describe how particular spatial relations reduce to topological sets. So in sdwgeo the topoRelations are disjoint from spatialRelations. May have to change to topoElementRelations. > 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 > 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. > 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. > I see that the property hasSerialization has three subproperties: asGML, asJSON and asWKT. But GML, JSON and WKT have very different levels of expressiveness. For example, WKT has no way of expressing CRS or resolution. JSON, on the ohter hand, is a very general format so it is not so clear what the serialization would look like. Or did you mean GeoJSON? So these need more exact definition (asGML and asWKT are defined in the GeoSPARQL spec, but not necessarily the way we want them to be, e.g. EWKT). My intent with asJSON is a JSON list of coordinates. That would presumably be identical to the coordinate property in GeoJSON given CRS = 'CRS84' > 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 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? > 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. > 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. > I see a property 'resolution' has been defined. But it does not seem to be related to other entities. Will it be a property of SpatialModel? Yes > 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. > Can the range of spatialDimension be specified as one the integers 1, 2 or 3? To start ;>) > > This is what I've come up with now. Probably questions will disappear or form when understanding increases. Having a set of examples of how the ontology can be used would probably help a lot for that understanding, and I think that working of implementation examples from our own fields of work could be a fun & fruitful group activity. > > Greetings, > Frans
Received on Friday, 23 September 2016 19:41:50 UTC