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

Re: Decision needed for issue-38: about different models of spatial things.

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Wed, 6 Jul 2016 13:03:00 +0200
Message-ID: <CAFVDz40hbZGnxjOfW7EPxZmeq1v6Qb_BF5VT3vz2pYvjVe7X1g@mail.gmail.com>
To: SDW WG Public List <public-sdw-wg@w3.org>
Hello all,

If I correctly read the expressed sentiments, it seems we should resolve
issue-38 by adding a new use case and a new requirement. You can see my
proposal for doing that below. If you disagree with the proposal, please
let me know. Otherwise I will put it in the UCR document before the next
public working draft is published.

Regards,
Frans

*Use case*
*Title:* Modelling in the construction sector
*Contributed by*: Sander Stolk (Semmtech)
*Text:*
In civil engineering and asset management settings, data from different
domains exist alongside each other. Such data typically overlap and
complement each other. Think of design data (CAD), geospatial data (GIS),
and data for systems engineering (SE). These are produced by different
software, and use different perspectives - although they are quite possibly
about the same subject (e.g. a specific office building or road).
Problems arise when combining data about a single subject from different
perspectives, in an attempt to complement information from one with that of
another. This means terminology is needed to capture that resources may be
about the same subject but follow different perspectives. For example, here
are three example perspectives on the same subject: an office building:

   1. Real-world perspective. One way of describing the office building is
   to identify it directly with a URI and detail its properties. Ontologies
   specifically geared to capturing real-life objects in such a way, using a
   real-world perspective, are typically called object type libraries (or
   OTLs).
   2. Chart perspective. Another way of describing the office building is
   to have a set of coordinates and describe what those coordinates on the map
   represent. In other words, the information is not about the office building
   itself but about coordinates that represent the building and how we should
   interpret those coordinates. In such a case, the building is captured in a
   charted representation.
   3. Format perspective. A third way of describing the office building
   could be by having it arranged in a format of which the exact semantics is
   not yet made explicit in the Semantic Web, such as content arranged
   according to an XML structure.

The perspectives above are not exhaustive. What they exemplify is that
vastly different perspectives of the world and its real-life objects exist.
Resources that are about the same subject and are captured using the same
perspective, or representation, can often be considered equal or identical.
Attributes captured for the one can then be said to also hold for the
other. Resources captured using different perspectives, however, cannot be
deemed equals. The one resource is then, for example, a registration of the
other.
If differences in perspective are not identified and made explicit, an
attempt at integrating data from different perspectives is likely to lead
to false conclusions. For instance, that a tangible office building in the
real world is also a vector of coordinates, and that it has a filled out
table cell called 'shape'.
It is exactly such relations between resources, signalling differences in
perspective (e.g. that one resource is a registration of another), that
should be able to be captured using explicit and standardized properties.
This problem is present in several projects in the construction domain
where integration of data from different perspectives plays a role. An
example is
http://www.rws.nl/english/about-us/doing-business-with-rijkswaterstaat/v-con/index.aspx.
However, data from these projects are currently not open.
*Related requirements:*

   - #Linkability
   - #SubjectEquality

*Requirement*
*Title:* Subject equality
*Text:*
There should be a recommended way to express that data based on different
models are about the same real world spatial object.
*Related deliverable(s):* Best Practices
*Related use case(s):* Modelling in the construction sector



2016-06-22 16:35 GMT+02:00 Joshua Lieberman <jlieberman@tumblingwalls.com>:

> It is great that someone recognizes this issue out in the wild. The
> challenge of dissonant cognition — incommensurate discernment of features —
> has been a pet project for many years. Boyan Brodaric has approached this
> in the past through pragmatics - the purpose behind specific discernments —
> and “hacked” RDF to express it.
>
> For the purposes of spatial data on the Web, the specific concern may be
> to indicate when properties of features can be integrated, based on some
> reconciliation of dissonance. That could be a set of feature / spatial
> thing relations that indicate to what degree and in what sense there is
> overlap in the conceptualization and/or location. In the case of building
> as part collection and building as located structure, it could be both
> sameLocation and sameMaterial, of example.
>
> I don’t think there is anywhere near a general best practice here, but it
> wouldn’t hurt to have it as a case for developing (and perhaps later
> codifying) one.
>
> Josh
>
>
> On Jun 22, 2016, at 8:25 AM, 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
>
>
>
>
Received on Wednesday, 6 July 2016 11:03:31 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:23 UTC