W3C home > Mailing lists > Public > public-sdw-wg@w3.org > July 2016

RE: Wanted: feedback on UCR requirements

From: Linda van den Brink <l.vandenbrink@geonovum.nl>
Date: Mon, 25 Jul 2016 07:36:29 +0000
To: Joshua Lieberman <jlieberman@tumblingwalls.com>, Rob Atkinson <rob@metalinkage.com.au>
CC: Frans Knibbe <frans.knibbe@geodan.nl>, Jeremy Tandy <jeremy.tandy@gmail.com>, Payam Barnaghi <payam.barnaghi@gmail.com>, "SDW WG Public List" <public-sdw-wg@w3.org>, Simon Cox <Simon.Cox@csiro.au>, "Kerry Taylor" <Kerry.Taylor@csiro.au>, Armin Haller <armin.haller@anu.edu.au>, Krzysztof Janowicz <janowicz@ucsb.edu>
Message-ID: <13F9BF0BE056DA42BFE5AA6E476CDEFE725F2CBF@GNMSRV01.gnm.local>
Also see this email from the Kadaster https://lists.w3.org/Archives/Public/public-sdw-comments/2016Jul/0000.html for more discussion on CRS specification on data.

They have problems with how CRS is specified as a part of the string in geosparql:asWKT. At the moment, they solve the problem by introducing a subPropertyOf asWKT, for every CRS. But they are looking for a better solution and suggest doing it just like a language tag, for example: geosparql:asWKT “POINT(53,2 5,6)”@EPSG:28992; and a function to check for a particular CRS, similar to lang(), for example: crs(?wkt) (which would result a literal or maybe a IRI representing the CRS). And/or a function for coordinate transformation.

In addition they suggest having content negotiation available for CRS’s as well.

Van: Joshua Lieberman [mailto:jlieberman@tumblingwalls.com]
Verzonden: woensdag 20 juli 2016 14:50
Aan: Rob Atkinson
CC: Linda van den Brink; Frans Knibbe; Jeremy Tandy; Payam Barnaghi; SDW WG Public List; Simon Cox; Kerry Taylor; Armin Haller; Krzysztof Janowicz
Onderwerp: Re: Wanted: feedback on UCR requirements

Hi Rob,

Yes, there are similarities. To summarize Jeremy’s summary, there seem to be be 4 things we want out of these sorts of linkages:

1) Controlled code or label for the value of the property in question —  CRS, UoM, Phenomenon, etc.
2) Web-accessible reference to the definition of a property value, preferably allowing interchange of property definition system or vocabulary
3) Scheme for minting new labels / definitions
4) Machine-accessible property value definition, preferably with formal semantics that allows inference or at least computation of relations between values (e.g. re-projection, unit conversion).

This may be somewhat easier with CRS, since there are well established definitions and encodings that can are read by projection libraries. The label versus reference concern ( 1) versus 2)) still exists, however. I’ve include a simple crs property for geometries with an xsd:anyURI literal, but also CRS as a form of spatial model that can use an asWKT property for example. I haven’t addressed eithe 3) or 4) to this point, though.

—Josh


On Jul 19, 2016, at 7:11 PM, Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>> wrote:

Hi Josh

please refer the the UoM discussion, and in particular Jeremy's summary - for a discussion of the challenges related to default vs label vs URI vs embedded model - this seems to apply to CRS as well as UoM.  I'm supposing that the spatial ontology will want represent what we regard as a BP in this regard (unless we have a million ad-hoc options in play) - so keen to get your input on what this might look like in practice.

Rob


On Tue, 19 Jul 2016 at 23:51 Joshua Lieberman <jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>> wrote:
The sdwgeo ontology includes a crs property for geometries, separately from whatever  might be within a serialization, e.g. for WKT. The additional question is whether a new crs vocabulary is needed or a URI reference to existing crs definitions is sufficient.

Josh

Joshua Lieberman, Ph.D.
Principal, Tumbling Walls Consultancy
Tel/Direct: +1 617-431-6431
jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>

On Jul 19, 2016, at 04:34, Linda van den Brink <l.vandenbrink@geonovum.nl<mailto:l.vandenbrink@geonovum.nl>> wrote:
Hi Frans, fellow BP editors,

Issue-29, about a way to link geometries to CRS, is something I’m getting questions about from ‘the wild’; that is: the Dutch Kadaster where they are busily publishing spatial linked data). They are looking for a way to link geometries to CRS. I have an email from them explaining what they need and what their current workaround is, but it’s in Dutch.

Linda

Van: Frans Knibbe [mailto:frans.knibbe@geodan.nl]
Verzonden: donderdag 14 juli 2016 15:31
Aan: Jeremy Tandy; Linda van den Brink; Payam Barnaghi; Simon Cox; Kerry Taylor; Krzysztof Janowicz; Armin Haller
CC: SDW WG Public List
Onderwerp: Re: Wanted: feedback on UCR requirements

Dear fellow editors,

I am happy to report that the current draft of the UC&R is now free of those pesky red notifications of unresolved issues. Many thanks for your help with that! However, the tracker still lists two things that need to be done:

Issue-29<https://www.w3.org/2015/spatial/track/issues/29> is about a possible new requirement for the BP deliverable. Could the BP team please have a look?

Action-111<https://www.w3.org/2015/spatial/track/actions/111> is about possibly adding use cases and requirements that were used for the existing SSN vocabulary. Could the SSN team please have a look and make a decision?

Thanks in advance,
Frans

On 22 June 2016 at 13:12, Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>> wrote:
Dear editors of the BP/Time/SSN/Coverage deliverable,

In preparation of a next public working draft of the UCR document I would like to ask you for feedback on the requirements for your deliverable as specified in the UCR document. Section 6<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#RequirementsByDeliverable> list requirements grouped by deliverable. By now you will have stared long & hard at those requirements, and perhaps you concluded that some or not clear yet, or that something else is wrong. Perhaps requirements or even important use cases are missing?

While we are working on a new batch of publications before TPAC, it would be nice if the requirements in the UCR document are (among) the ones you are actually working with. I think the public we are writing for deserves that coherence. I presume your deliverables will link back to the UCR document and explain how requirements are met or why requirements are not met. So if you think any changes are required in the UCR document resulting from your work on your deliverable, please inform me.

Thanks,
Frans


Received on Monday, 25 July 2016 07:37:05 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 September 2016 12:03:24 UTC