New project proposal: OWL Space

[FransKnibbe]

In the footsteps of the OWL Time ontology, a domain independent web ontology for spatial data should be developed, allowing unification of the many different models, exchange formats and storage formats for spatial data.

One possible approach is to start with GeoSPARQL and extend it to allow usage for other purposes next to vector geography.

A more elaborate call to arms can be found in this message: https://lists.w3.org/Archives/Public/public-sdwig/2018Oct/0090.html. Also notable is the follow-up discussion on the list.

Other discussion threads on the SDWIG public list in which the idea of a spatial ontology is discussed:

• https://lists.w3.org/Archives/Public/public-sdwig/2018Oct/0067.html
• https://lists.w3.org/Archives/Public/public-sdwig/2018Oct/0106.html (crossover from the Linked Building Data Community Group)

Prior art

Following is a list of web resources that are relevant to the idea of a cross-domain spatial ontology for web data.

• QB4ST (an extension of the Data Cube vocabulary for spatio-temporal data) mentions the lack of a foundation ontology for spatial concepts.
• The Spatial Data on the Web Best Practices document signals the need for an update of GeoSPARQL to cover more use cases.
• The GML vocabulary published by the OGC: http://www.opengis.net/ont/gml.
• The CRS vocabulary published by the IGNF: http://data.ign.fr/def/ignf.
• A proposal for support of Coordinate Reference Systems in SVG (SVG is a W3C standard for 2D vector data on the web).
• Documentation of the geospatial capabilities of x3dom
  (x3dom is a javascript library for handling X3D on web pages. X3D strives to become a standard for 3D vector data on the web).
• ISO 19111 (Geographic Information - Spatial referencing by coordinates_) and the corresponding OGC specification contains a definitions for non-geographical coordinate systems (EngineeringCRS) . Derived ontologies can be found here.
• Industry Foundation Classes (IFC) is a standard for exchange of BIM data. It has increasing capabilities to specify geography, as shown by the recent addition of [IfcCoordinateReferenceSystem](http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifcrepresentationresource/lexical/ifccoordinatereferencesystem.htm.
• ISO 19148 (Geographic information - Linear referencing; no free corresponding OGC document seems to be available) covers locations relative to linear features (which is not limited to geography).
• The 3D Tiles specification combines geospatial standards with glTF, a data format used in 3D visualisation.
• This SDWIG issue is about use cases for WebVMT that involve non-geographical spatial data.
• The start of on extension to GeoSPARQL: GeoSPARQL Extensions Ontology.
• Draft of a more modular version of GeoSPARQL: https://geosemweb.org/sdwgeo.
• Draft of a version of GeoSPARQL that is closer to GeoRSS: https://geosemweb.org/ogeo.

[chris-little]

Hi Frans,
I think it important to get the scope defined. The 2017 OWL-Time ontology went for full backward compatibility with OWL-Time 2006, which may cause problems, as the previous version has the TimeDate construct which, to me, is a not very clean compromise between coordinates and calendars.
So, first question: are both Euclidean ('straight') and Riemannian ('curved') coordinate spaces envisaged?
Second question: are both continuous (as in first question) and discrete ('nodes and arcs') reference systems envisaged?
Perhaps I have just defined quadrants to think about?

My colleague Mark Hedley has also just asked me to think about the difference between a Coordinate System and a Coordinate Reference System. "More grist to the mill" as we say in English.

Chris

[FransKnibbe]

Hello Chris,

Backward compatibility should certainly be a requirement, or at least something to try to achieve as well as possible. I am hopeful that it will be possible to ensure compatibility with existing standards by including the real mathematical foundations in the ontology. There are many models, standards, storage formats and exchange formats for spatial data. But they all should be compatible at a fundamental level. So with the ability to define everything in fundamental terms, backward compatibility should be achievable (fingers crossed).

To answer your questions:

1. With my background in geography, I think there should at least be support for Cartesian, curved linear, and spherical coordinate spaces, up to three dimensions. That partly includes Euclidean and Riemannian coordinate spaces. So I guess the answer should be yes.
2. By 'discrete references systems', do you mean a system that uses a tessellation to indicate location (as in Discrete Global Grid Systems)?

As for CS vs CRS: At least in the geography domain the definition seems to be that a CRS is a CS plus a datum. Datums are important to define and to share data about, but not required for all spatial expressions. So coordinate systems and datums should probably be separate things in the ontology, but combinable.

Greetings,
Frans

[chris-little]

Hi Frans,
Re (2), No, I did not really mean tessellations, but that is perhaps a helpful way to think. DGGS is definitely not what I meant. In the time ontology, there is the possibility of the simplest temporal ordering of events, linked to geological or archaeological layers, king lists, ice cores, with reasoning (before, after, during, overlapping, etc). There is no concept of duration, just ordering.

I envisage that there may be a simple spatial 'ordering', but without distance. Two things may be adjacent, or 'further away' with more intermediate adjacent things. Nodes on a network are the obvious example.

Tesellations are not quite the same, as most tesselations involve a proper distance/measure to get precise shapes. They straddle both ideas. As does DGGS if (measured) location is replaced by a (counted) location of grid cell identifier.

[chris-little]

In other terms, I am suggesting that, rather than start with measures/CRS/datum/etc, start with the proximity algebras such as https://en.wikipedia.org/wiki/DE-9IM and perhaps the 3D equivalent .

[FransKnibbe]

Ah, I understand. Yes, starting with topological relationships could be a good idea. An ontology has to start somewhere, and if it is possible to start without touching the difficult subject of coordinate systems perhaps starting there could make a smooth beginning.

A good source of information on that topic seems to be Topological Relationships and Their Use, which describes 69 different relationships in 1, 2 or 3 dimensions.

As a starting point I earlier considered starting with the definition of a point in a 1, 2 or 3 dimensional cartesian coordinate space. As it would probably wise to modularize a spatial ontology, having multiple simple starting points (in separate modules) could also be an option.

As for relative proximity of nodes in a network: isn't graph theory essentially non-spatial? I know graphs are used for spatial problems, but does that warrant inclusion in a spatial ontology?

[6a6d74]

During the SDW-IG teleconference on 16-Jan (minutes: www.w3.org/2019/01/16-sdw-minutes.html) we said:

OWL Space proposal
brinkwoman: I was talking with Jo yesterday about that. Sometimes, people referred to the idea as spatial ontology. Jo joined me as co-chair of the OGC GeoSemantic Working Group.
(Related to the previous item - we’ll all try to review the API Guidelines by the beginning of Feb - we’ll coordinate the input via the SDW group discussion)
brinkwoman: We wanted to move the topic to the Geosemantic Working Group. A Domain Working Group from an OGC perspective, which is open to non OGC people.
jtandy: That sounds fine with me. It would also give some focus to the Geosemantic Working Group.
josephabhayaratna: Having a working group plan to work on it seems a good thing.
+1
+1
+1
<RobSmith_> +1
billroberts: Sounds like a good idea. We discussed in the best practices some of the things missing from GeoSparql. I would concentrate on the simple bits as far as practical.
… My general feeling about using ontologies is that most people don't care about the fancy bits. If we can standardize the core things, then that's good.
josephabhayaratna: Just to follow up. Driving it from work that is already happening. Trying to keep it focused and relevant.
… Having a look at problems that people really have. We want to bring people that are struggling with concrete problems.
sounds like the ideal approach to me, Jo - thanks
jtandy: Linda or Jo, if you can take an action to update the issue and point people at the right OGC group, that would be good
josephabhayaratna: Happy to take that action.
brinkwoman: Should we create a proper project for it?
jtandy: Yes, move it to a concrete project

So - it looks like we have some concrete proposals, with endorsement from the IG.

Actions / decisions:

1. Pursue this work within the OGC Geosemantics DWG - it's a DWG, so it's open to non-OGC members
2. Create a new Project for this activity in the SDW repo

@jabhay - would you be the best person to own this push it forward?

[marqh]

Hello

I think that specification of Coordinate Reference Systems is key to a representation of geolocation within a Space Ontology.

There are recent activities from within OGC & ISO, extending the Coordinate Reference System Model (ISO19111) (docs.opengeospatial.org/as/18-005r4/18-005r4.html)
and providing an encoding format for instances of Coordinate Reference System Definitions.
(ISO19162) (updated with respect to 19111, not yet published by OGC/ISO, but imminent)
(a previous iteration is available here http://docs.opengeospatial.org/is/12-063r5/12-063r5.html)

This is a wide ranging and complicated topic.
Initially this may be able to be sensibly handled by referencing out to these standards and encodings, rather than implementing all the details explicitly within an Ontology. This may at least provide a valuable first step

For example, a URI referencing a CRS entity defined in text using Well Known Text for Coordinate Reference Systems might provide a basis for spatial referencing within the proposed Space Ontology.

The complications involved in representing the Coordinate Reference System model fully within an Ontology may be seen as intellectually interesting, but could be a significant activity in its own right, without bringing proportionate benefit.

I am happy to provide some more input on this if it is valuable

mark

[FransKnibbe]

Hello,

It is great to see the idea being moved forward. And to a community group that is free for everyone to join too. I think that's very important.
A concern could be that when something actually will be developed, it will be too heavily focused on geographic data. If that happens, the desire of aiding cross-domain interoperability could be at risk. And I really think that should be a core requirement, however small or modest the beginnings might be. So it will be important to reach out to people that by nature do not flock to OGC community groups and might have never heard of the OGC in the first place. Luckily, the OGC is already in a process of expanding its interests wider than basic geography, so that would not be breaking current practice, so it seems.

Greetings,
Frans

[FransKnibbe]

1. Pursue this work within the OGC Geosemantics DWG - it's a DWG, so it's open to non-OGC members

Is the OGC Geosemantics DWG really open to non-OGC members? Here is part of the reply I got after having tried to subscribe to the e-mail list:
'Your request to the GeoSemWeb mailing list
Subscription request
has been rejected by the list moderator. The moderator gave the following reason for rejecting your request:
"This is an OGC member's only list.
...'

To become a member of the OGC as an individual, it seem I would have to pay USD 550 per year.

Regards,
Frans

[ogcscotts]

Hi Frans - I am looking into the list moderation as this list is supposed to be public.
Scott

[lieberjosh]

Hi, Thought we’d made the geosemantics list public, but the group is not. The Spatial Data on the Web Interest Group is supposed to be public, I believe, and is in essence also a Geosem subgroup.

…

-Josh

On Mar 12, 2019, at 1:50 PM, Scott Simmons ***@***.***> wrote: Hi Frans - I am looking into the list moderation as this list is supposed to be public. Scott — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ogcscotts]

The list is now public, so please try again to subscribe, Frans.
Scott

[FransKnibbe]

Scott, Josh, thank you for being on the case. I have just tried to subscribe again. And this time the subscription was succesful.

[lvdbrink]

Under discussion in GeoSemantics DWG (OGC)

[nicholascar]

I have just presented on the Australian spatial Linked Data infrastructure LocI at the European Semantic Web Conference yesterday and discussed with a number of attendees possible enhancements to the GeoSPARQL Ontology which could be picked up in OWL Space. There seems to be a common set of requirements from at least attendees here, some of which I’ve placed in my informally presented and open-ended GeoSPARQL Extensions Ontology: https://github.com/CSIRO-enviro-informatics/geosparql-ext-ont. I will soon publish that small ontology, after some additions and a review, since we need to use it now.

[kjano]

Hi, I am all for these ideas but I have reservations about the name. OGC (and Simon can correct me) has this great distinction between abstract specifications and implementation specifications. I do believe that we need a better and more modern `Space Ontology', and I also believe that we should have an OWL and SHACL implementation of this ontology. Best, Jano

…

On 6/6/19 6:03 AM, Nicholas Car wrote: I have just presented on the Australian spatial Linked Data infrastructure LocI at the European Semantic Web Conference yesterday and discussed with a number of attendees possible enhancements to the GeoSPARQL Ontology which could be picked up in OWL Space. There seems to be a common set of requirements from at least attendees here, some of which I’ve placed in my informally presented and open-ended GeoSPARQL Extensions Ontology: https://github.com/CSIRO-enviro-informatics/geosparql-ext-ont. I will soon publish that small ontology, after some additions and a review, since we need to use it now. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1095?email_source=notifications&email_token=AANMP5R66D6ONTPDWTX77WLPZEDLFA5CNFSM4GDZBJ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXCYN5I#issuecomment-499484405>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANMP5XXJNAFSE2GH37IKMTPZEDLFANCNFSM4GDZBJ3Q>.

-- Krzysztof Janowicz Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 Email: jano@geog.ucsb.edu Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net

[dr-shorthair]

Indeed. What notation should be used for an abstract ontology? (OGC/ISO mostly used UML for the abstract spec, and various XML/JSON/DDL specs for implementations.) Simon From: kjano [mailto:notifications@github.com] Sent: Friday, 7 June, 2019 03:20 To: w3c/sdw <sdw@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [w3c/sdw] New project proposal: OWL Space (#1095) Hi, I am all for these ideas but I have reservations about the name. OGC (and Simon can correct me) has this great distinction between abstract specifications and implementation specifications. I do believe that we need a better and more modern `Space Ontology', and I also believe that we should have an OWL and SHACL implementation of this ontology. Best, Jano

…

On 6/6/19 6:03 AM, Nicholas Car wrote: I have just presented on the Australian spatial Linked Data infrastructure LocI at the European Semantic Web Conference yesterday and discussed with a number of attendees possible enhancements to the GeoSPARQL Ontology which could be picked up in OWL Space. There seems to be a common set of requirements from at least attendees here, some of which I’ve placed in my informally presented and open-ended GeoSPARQL Extensions Ontology: https://github.com/CSIRO-enviro-informatics/geosparql-ext-ont. I will soon publish that small ontology, after some additions and a review, since we need to use it now. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1095?email_source=notifications&email_token=AANMP5R66D6ONTPDWTX77WLPZEDLFA5CNFSM4GDZBJ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXCYN5I#issuecomment-499484405>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANMP5XXJNAFSE2GH37IKMTPZEDLFANCNFSM4GDZBJ3Q>.

-- Krzysztof Janowicz Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu> Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1095?email_source=notifications&email_token=AAEUQL5OFM6TQ3JE6GV23ULPZFBM3A5CNFSM4GDZBJ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXDRZ4I#issuecomment-499588337>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAEUQL2CA7KHBG4HR5QQ6VTPZFBM3ANCNFSM4GDZBJ3Q>.

[lieberjosh]

It’s not just OGC, but is referred to as the Cook & Daniels methodology by Werner Kuhn and others. RDF seemed to be this great opportunity to have less of a stark difference between concept / type and instance / tuple. Perhaps because RDF can also be used for implementation or just because of familiarity, OGC has been reluctant to move from UML towards RDF / OWL as a language of abstraction despite dissonance between UML and many implementation languages. With domain conceptual models, type catalogs, etc., the abstract <-> implementation dichotomy really isn’t what it used to be anyways, even in OGC. That said, there is at least an update of the spatial schema (geometry, topology) abstract spec (AS Topic 1 / ISO 19107). Plenty of concepts to drag into OWL/RDF as long as it isn’t done robotically. As far as an update to GeoSPARQL, I’ve tried to push this for a while, but my sense is that there has not been much agreement on what the requirements for such an update might be. I tried in SDWWG days to modularize it (sdwgeo) and bring a core closer to GeoRSS (ogeo), but there wasn’t much interest. Some concerted effort to figure out what is needed might get past the pitfalls of special needs that most other spatial ontologies seem to fall into. The drafts are still here: https://geosemweb.org/ogeo <https://geosemweb.org/ogeo> and https://geosemweb.org/sdwgeo <https://geosemweb.org/sdwgeo>. We will have the opportunity to discuss GeoSPARQL update prospects in the Geosemantics DWG in Leuven and try to progress in understanding what the needs might drive this. —Josh

…

On Jun 6, 2019, at 11:17 PM, Simon Cox ***@***.***> wrote: Indeed. What notation should be used for an abstract ontology? (OGC/ISO mostly used UML for the abstract spec, and various XML/JSON/DDL specs for implementations.) Simon From: kjano ***@***.*** Sent: Friday, 7 June, 2019 03:20 To: w3c/sdw ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [w3c/sdw] New project proposal: OWL Space (#1095) Hi, I am all for these ideas but I have reservations about the name. OGC (and Simon can correct me) has this great distinction between abstract specifications and implementation specifications. I do believe that we need a better and more modern `Space Ontology', and I also believe that we should have an OWL and SHACL implementation of this ontology. Best, Jano On 6/6/19 6:03 AM, Nicholas Car wrote: > > I have just presented on the Australian spatial Linked Data > infrastructure LocI at the European Semantic Web Conference yesterday > and discussed with a number of attendees possible enhancements to the > GeoSPARQL Ontology which could be picked up in OWL Space. There seems > to be a common set of requirements from at least attendees here, some > of which I’ve placed in my informally presented and open-ended > GeoSPARQL Extensions Ontology: > https://github.com/CSIRO-enviro-informatics/geosparql-ext-ont. I will > soon publish that small ontology, after some additions and a review, > since we need to use it now. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#1095?email_source=notifications&email_token=AANMP5R66D6ONTPDWTX77WLPZEDLFA5CNFSM4GDZBJ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXCYN5I#issuecomment-499484405>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AANMP5XXJNAFSE2GH37IKMTPZEDLFANCNFSM4GDZBJ3Q>. > -- Krzysztof Janowicz Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 Email: ***@***.******@***.***> Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1095?email_source=notifications&email_token=AAEUQL5OFM6TQ3JE6GV23ULPZFBM3A5CNFSM4GDZBJ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXDRZ4I#issuecomment-499588337>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAEUQL2CA7KHBG4HR5QQ6VTPZFBM3ANCNFSM4GDZBJ3Q>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1095?email_source=notifications&email_token=ABGFNBUCK4UT456ODHWIU23PZHHOPA5CNFSM4GDZBJ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEXSYY#issuecomment-499743075>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABGFNBWHQ4N3NNFAUCWA3ODPZHHOPANCNFSM4GDZBJ3Q>.

[kjano]

On 6/6/19 8:17 PM, Simon Cox wrote: Indeed. What notation should be used for an abstract ontology? (OGC/ISO mostly used UML for the abstract spec, and various XML/JSON/DDL specs for implementations.)

I like something like the 'Simple Event Model' (SEM) [1]. We could even name the ontology LPPS for 'Locations, Positions, Places, and Spaces' and cover all of them as they are constantly confused in the literature and even more so in other ontologies. My main point is not to confuse the ontology with one potential language to represent it. If we want to make impact, we may be better served with a schema.org-like, and OWL, and a SHACL version to suit different needs and communities. IMHO, what matters most is the common model and less whether one implementation can express a bit more or less of the underlying model in terms of classical  reasoning or constrain checking. Best, Jano [1] https://homepages.cwi.nl/~hollink/pubs/vanHage2011SEM.pdf

…

Simon From: kjano ***@***.*** Sent: Friday, 7 June, 2019 03:20 To: w3c/sdw ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [w3c/sdw] New project proposal: OWL Space (#1095) Hi, I am all for these ideas but I have reservations about the name. OGC (and Simon can correct me) has this great distinction between abstract specifications and implementation specifications. I do believe that we need a better and more modern `Space Ontology', and I also believe that we should have an OWL and SHACL implementation of this ontology. Best, Jano On 6/6/19 6:03 AM, Nicholas Car wrote: > > I have just presented on the Australian spatial Linked Data > infrastructure LocI at the European Semantic Web Conference yesterday > and discussed with a number of attendees possible enhancements to the > GeoSPARQL Ontology which could be picked up in OWL Space. There seems > to be a common set of requirements from at least attendees here, some > of which I’ve placed in my informally presented and open-ended > GeoSPARQL Extensions Ontology: > https://github.com/CSIRO-enviro-informatics/geosparql-ext-ont. I will > soon publish that small ontology, after some additions and a review, > since we need to use it now. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#1095?email_source=notifications&email_token=AANMP5R66D6ONTPDWTX77WLPZEDLFA5CNFSM4GDZBJ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXCYN5I#issuecomment-499484405>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AANMP5XXJNAFSE2GH37IKMTPZEDLFANCNFSM4GDZBJ3Q>. > -- Krzysztof Janowicz Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 Email: ***@***.******@***.***> Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1095?email_source=notifications&email_token=AAEUQL5OFM6TQ3JE6GV23ULPZFBM3A5CNFSM4GDZBJ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXDRZ4I#issuecomment-499588337>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAEUQL2CA7KHBG4HR5QQ6VTPZFBM3ANCNFSM4GDZBJ3Q>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1095?email_source=notifications&email_token=AANMP5R34CC4VGJHHXFXQSDPZHHOLA5CNFSM4GDZBJ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEXSYY#issuecomment-499743075>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANMP5R4VDC5EZSQBJVQT3LPZHHOLANCNFSM4GDZBJ3Q>.

-- Krzysztof Janowicz Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 Email: jano@geog.ucsb.edu Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net

[FransKnibbe]

Hi all,

I have just added Nick's and Josh's ideas for improvement of GeoSPARQL to the list of prior art in the top message of this thread.

As for the name: at this point I think a name like 'OWL Space' should be considered to be no more than a placeholder label. However, I do think it is important for the ontology to be about space and not only geography. Having 'space' or 'spatial' in the name should help to make that clear.

Separating abstract and implementation specifications seems like a very good idea to me. An abstract specification is the thing that is really needed. And if it's is any good (clear, simple, modular, ...) it should be possible for anyone to come up with interoperable implementation specifications.

As for notation: I agree that the main effort should be to arrive at a clear model/knowledge representation, irrespective of notation. It is likely that the skeleton of the model will consist of related classes and properties, which can be done in either OWL or UML. That way of modelling knowledge has been popular at least since Aristotle. It will probable last for some time yet, while OWL and UML may turn out to be short-lived fads. Developing OWL and UML simultaneously could be an option and might even be a way to improve quality? I also agree that any translation between notations should not be done robotically.

Aside from OWL or UML, my gut feeling is that mathematics should be a main language in this model. Fortunately, maths is universal and chances are high that it will also stand the test of time.

A further consideration: one thing I really like about having at least a model in RDFS/OWL is that all definitions will have deferenceable and linkable URI's. That should help users and implementers a lot.

Greetings,
Frans

[FransKnibbe]

The proposal to start a general ontology for spatial data from GeoSPARQL has been added to the OGC issue tracker: http://ogc.standardstracker.org/show_request.cgi?id=592

[kjano]

Very good. KJ

…

On 9/18/19 5:44 AM, Frans Knibbe wrote: The proposal to start a general ontology for spatial data from GeoSPARQL has been added to the OGC issue tracker: http://ogc.standardstracker.org/show_request.cgi?id=592 <url> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1095?email_source=notifications&email_token=AANMP5TARRC22DVGZYT5CMTQKIPETA5CNFSM4GDZBJ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD675XYQ#issuecomment-532667362>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANMP5QSSTSAS6KPJ57OFATQKIPETANCNFSM4GDZBJ3Q>.

-- Krzysztof Janowicz Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 Email: jano@geog.ucsb.edu Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net

[lvdbrink]

GeoSemantics DWG is working on a white paper exploring the idea that semantic and graph technologies will increase the value that can be extracted from (geo)spatial data.

This paper has two purposes. Firstly, to describe the benefits of representing geospatial data using semantics and graph technologies. Secondly, to outline some shortcomings of the existing GeoSPARQL implementation specification that, if addressed, would unlock its potential to a greater extent.

@jabhay is leading this work.

See https://github.com/opengeospatial/geosemantics-dwg/tree/master/white_paper

[6a6d74]

This issue is now incorporated into the OGC GeoSPARQL Change Request. Consequently I'm closing this "proposal". Further discussion should take place in the relevant OGC forums. Thanks all!