[esip-semantictech] [AGENDA] ESIP SemTech Telecon - 2019-05-28

Tue May 28 21:34:54 EDT 2019

Simon,

Your general approach (which I think is to persist geometry representations
> outside the context of the feature, and link to them through URIs) makes
> sense, and I think essentially matches practice in GIS systems for decades
> now (where geometry was in a separate table).

The main idea is that RDF Literals are not suitable for complex geometry
data. Other than that, the data model is nearly the same as GeoSPARQL with
some extensions to provide metadata (e.g., attributes such as vertex count,
centroid, area, etc.) about the geometries themselves. Finally, we advise
that on-demand topology is too expensive on high-resolution geodata (such
spatial queries are not feasible at scale) and that for topology to be
practical, it needs additional context beyond merely the geometries alone
(even assuming they are cleaned) due to vagueness and uncertainty
principles; whereas precomputing metrically-refined topology with context
(e.g., what threshold to use for an approximate topological relation
between a forest and a lake) is not only feasible but also capable of
producing more meaningful relations than strict topological relations
(e.g., DE-9IM between spatial regions).

However, I’m not sure that you need a new vocabulary or namespace.   The
> definition of :hasGeometry in the GeoSPARQL standard[1] (clause 8.3.1.1) is
> It is an owl:ObjectProperty, but there is no requirement for the object to
> be a local blank-node. It can be a URI, as in your slide 18.

Thank you for being so observant! You are correct, it is already possible
to use URIs (i.e., instead of blank nodes) with GeoSPARQL as described in
the presentation; as you pointed out, this does not require use of a new
predicate. In fact, the approach here is fully compatible with GeoSPARQL in
theory, both in terms of the vocabulary in the data model and the
extensible value testing functions in SPARQL (e.g., geof:intersection,
geof:convexHull, etc.).

The reason we show a new predicate for hasGeometry is mostly to highlight
to the viewer that we are proposing something new here, not that we intend
to replace the GeoSPARQL ontology. In other words, these custom predicates
and classes have only been used for demonstration purposes and
proof-of-concepts so far. However, we could assume that such a predicate is
an rdfs:subPropertyOf geosparql:hasGeometry, or that the ago:Geometry class
is an rdfs:subClassOf geosparql:Geometry if it became necessary to add
e.g., property restrictions.

A set of properties are provided, one of which is geo:hasSerialization. WKT
> is only provided as an example, and is not mandatory - GML is included in
> GeoSPARQL as another option, but other representations are not prohibited
> thanks to the RDF open-world-assumption.

Yes, I also spoke about GML during the presentation; and again I am not
saying that anything about GeoSPARQL needs to be changed. I merely hope
that the community sees the benefits in using dereferenceable IRIs instead
of blank nodes for geometries (which we recommend for *all* non-point
features), and that complex geometries pose many challenges when encoded as
human-readable formats in RDF Literals.

You will likely also need to negotiate over the *schematic* form of the
> representation (e.g. neogeo vs geosparql).

Very interesting. I had not yet seen the draft for content negotiation by
profile. The negotiation concept for geometries certainly requires more
development -- there was also a comment on the call about negotiation and
available representations of geometries. On a related note, I think there
are several transactional aspects to consider when geometries are taken out
of RDF Literals including how to deal with versioning, Linked Data
Platform, Web Feature Service, and Web Processing Service.

 - Blake

On Tue, May 28, 2019 at 4:09 PM Cox, Simon (L&W, Clayton)
<Simon.Cox at csiro.au> wrote:

> Thanks Blake –
>
> Sorry I missed your presentation. Somehow it had dropped out of my
> calendar.
>
>
>
> I’ve looked through your slides. Your general approach (which I think is
> to persist geometry representations outside the context of the feature, and
> link to them through URIs) makes sense, and I think essentially matches
> practice in GIS systems for decades now (where geometry was in a separate
> table).
>
>
>
> However, I’m not sure that you need a new vocabulary or namespace.   The
> definition of :hasGeometry in the GeoSPARQL standard[1] (clause 8.3.1.1) is
>
>
>
> geo:hasGeometry a rdf:Property,
>
> owl:ObjectProperty;
>
> rdfs:isDefinedBy <http://www.opengis.net/spec/geosparql/1.0>;
>
> rdfs:label "has Geometry"@en;
>
> rdfs:comment "A spatial representation for a given feature."@en;
>
> rdfs:domain geo:Feature;
>
> rdfs:range geo:Geometry .
>
>
>
> It is an owl:ObjectProperty, but there is no requirement for the object to
> be a local blank-node. It can be a URI, as in your slide 18.
>
>
>
> You may worry about the rdfs:range, which is given as geo:Geometry, which
> is defined in clause 8.4. A set of properties are provided, one of which is
> geo:hasSerialization. WKT is only provided as an example, and is not
> mandatory - GML is included in GeoSPARQL as another option, but other
> representations are not prohibited thanks to the RDF
> open-world-assumption.  There is merely the entailment that the object of a
> geo:hasGeometry property is a member of the class geo:Geometry.
>
>
>
> As you note, content negotiation for representations of a geometry will be
> helpful.
>
> However, format (serialization) negotiation using HTTP Accept: is only
> part of the story.
>
> You will likely also need to negotiate over the *schematic* form of the
> representation (e.g. neogeo vs geosparql).
>
> This is the topic of an upcoming W3C note from the Data Exchange Working
> Group ‘Content Negotiation by Profile’[2].
>
>
>
> Simon
>
>
>
> [1] https://portal.opengeospatial.org/files/?artifact_id=47664
>
> [2] https://w3c.github.io/dxwg/conneg-by-ap/
>
>
>
> *From:* esip-semanticweb [mailto:
> esip-semanticweb-bounces at lists.esipfed.org] *On Behalf Of *Blake Regalia
> via esip-semanticweb
> *Sent:* Wednesday, 29 May, 2019 07:13
> *To:* Mcgibbney, Lewis J (398M) <lewis.j.mcgibbney at jpl.nasa.gov>
> *Cc:* esip-semanticweb at lists.esipfed.org; Mike Daniels <daniels at ucar.edu>
> *Subject:* Re: [esip-semantictech] [AGENDA] ESIP SemTech Telecon -
> 2019-05-28
>
>
>
> Slides from today's presentation:
>
>
>
>
> https://www.slideshare.net/BlakeRegalia/towards-a-more-efficient-paradigm-of-storing-and-querying-spatial-data-on-the-semantic-web
>
>
>
>  - Blake Regalia
>
>
>
>
>
> On Thu, May 23, 2019 at 4:12 PM Mcgibbney, Lewis J (398M) <
> lewis.j.mcgibbney at jpl.nasa.gov> wrote:
>
> Hi esip-semanticweb,
>
> This is a courtesy email regarding preparation for our next telecon.
>
> We will be hosting Blake Regalia, UCSB who will be “…Revisiting the
> Representation of and Need for Raw Geometries on the Linked Data Web”.
>
>
>
> After Blake’s presentation, we will use the remainder of our time to
> discuss the science-on-shcema.org proposal which can be found at
> https://docs.google.com/document/d/1O539ROr9W7FUEDzR2ni2H2Doxx_2zK8AF-sma8pBDe0/edit?usp=sharing
>
> Mike Daniels will be joining us for that.
>
>
>
> Our meeting minites can be found at
> https://docs.google.com/document/d/19agZraGms4vsv7S2SP0SpPWuTtfIQOet4NkyvMUEClQ/edit#heading=h.yn5iw79j9hmd
> SemTech Monthly Telecon
>
>    - 4th Tuesday of each month at 4pm Eastern
>    - GoToMeeting: https://www.gotomeeting.com/join/976796333
>    - Phone Access: United States: +1 (872) 240-3212
>    - Access Code: 976-796-333
>
>
>
> Lewis
>
>
>
> Dr. Lewis John McGibbney Ph.D., B.Sc.(Hons)
>
> Data Scientist III
>
> Computer Science for Data Intensive Applications Group (398M)
>
> Instrument Software and Science Data Systems Section (398)
>
> Jet Propulsion Laboratory
>
> California Institute of Technology
>
> 4800 Oak Grove Drive
>
> Pasadena, California 91109-8099
>
> Mail Stop : 158-256C
>
> Tel:  (+1) (818)-393-7402
>
> Cell: (+1) (626)-487-3476
>
> Fax:  (+1) (818)-393-1190
>
> Email: lewis.j.mcgibbney at jpl.nasa.gov
>
> ORCID: orcid.org/0000-0003-2185-928X
>
>
>
>            [image: signature_492949258]
>
>
>
>  Dare Mighty Things
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.esipfed.org/pipermail/esip-semanticweb/attachments/20190528/f6d970bd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3432 bytes
Desc: not available
URL: <http://lists.esipfed.org/pipermail/esip-semanticweb/attachments/20190528/f6d970bd/attachment-0001.png>