- From: Jeremy Tandy <jeremy.tandy@gmail.com>
- Date: Wed, 22 Jun 2016 12:53:59 +0000
- To: Ed Parsons <eparsons@google.com>, Frans Knibbe <frans.knibbe@geodan.nl>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CADtUq_3a2iRfRrigXUN4C+-KB5wTcyqULkbpT7uYCdo8Bn5Vig@mail.gmail.com>
"stuff we don't know but someone needs to address" +1 to this being a useful part of the BP doc. We can't give a solution because there is no practice for us to refer to. Also this problem strays into the "dragons" of object reconciliation- which as we commented (much) earlier is a hard problem. Jeremy On Wed, 22 Jun 2016 at 13:36, Ed Parsons <eparsons@google.com> wrote: > I can certainly see there is a real use case, and resulting requirement(s) > from this, and while it sits mostly obviously within the BP deliverable my > guess is there is no obvious solution to the issue. So we need to ask > ourselves is it worth going through the process to document all of this > without a potential solution in mind? > > I personally think we should as it gives insight to others in terms of > future work... in fact I think a really useful part of the BP deliverable > will be the "stuff we don't know but someone needs to address" > > Ed > > > On Wed, 22 Jun 2016 at 13:26 Frans Knibbe <frans.knibbe@geodan.nl> wrote: > >> Hello, >> >> One UCR issue that really deserves some urgent progress is issue-38 >> <https://www.w3.org/2015/spatial/track/issues/38>. It is about a >> possible new use case and possible new requirements as a result from a >> submission from the public. See the thread Additon to use case & new req >> <https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jan/0093.html>. >> >> The heart of the matter seems to be that people are missing a way to >> express that two different sets of data about a real world thing are about >> the same real world thing, when the two sets of data use different >> information models, one of which could be geospatial. An example is a >> building. There could be a batch of data describing the building as a >> spatial feature, using spatial semantic standards, and there could be >> another batch of data describing the building as a collection of building >> materials, using some other semantic standard. The submitters of the >> problem feel that there is no way to express that both batches of data are >> about the same subject and that the two batches of data could complement >> each other. Properties like owl:sameAs >> <http://www.w3.org/TR/2004/REC-owl-semantics-20040210/#owl_sameAs>, >> rdfs:seeAlso <https://www.w3.org/TR/rdf-schema/#ch_seealso>, umbel:isLike >> <http://wiki.opensemanticframework.org/index.php/UMBEL_Vocabulary#isLike_Property> >> , bbccore:sameAs >> <http://www.bbc.co.uk/ontologies/coreconcepts#terms_sameAs> and >> http://schema.org/about are regarded as insufficient or inappropriate. >> >> The submitters admit that the problem is not in the spatial domain, but >> feel that the broader W3C communities have yet failed to address the >> problem and that addressing the problem bottom-up, with a clear use case >> and with a certain (spatial) scope could lead to a solution that could >> later be applied more generally. >> >> I am not sure what we should do. On the one hand I think we should guard >> our scope, and not take on things that are really of a broader nature than >> spatial data. On the other hand, this is a real world problem that exists >> with spatial data and that hinders using combining traditional geospatial >> data with other sorts of data. And identifying a requirement is not the >> same as promising to meet that requirement. >> >> If we were to accept this use case, I guess the resulting requirement >> should be something like "It should be possible to express that spatially >> modelled data are about the same subject as data using other information >> models". And I guess that would be a BP requirement. >> >> What do you think? How can we resolve this issue? >> >> Regards, >> Frans >> >> >> -- > > *Ed Parsons *FRGS > Geospatial Technologist, Google > > Google Voice +44 (0)20 7881 4501 > www.edparsons.com @edparsons >
Received on Wednesday, 22 June 2016 12:54:41 UTC