- From: Joshua Lieberman <jlieberman@tumblingwalls.com>
- Date: Wed, 20 Jul 2016 08:49:59 -0400
- To: Rob Atkinson <rob@metalinkage.com.au>
- Cc: Linda van den Brink <l.vandenbrink@geonovum.nl>, 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: <5C1D1821-C82C-4218-AEF7-2C67158A2635@tumblingwalls.com>
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> 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 <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 Wednesday, 20 July 2016 12:51:13 UTC