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

Well, I have received no objections so I have just added the new use case
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#ModellingInTheConstructionSector>
and
the new requirement
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SubjectEquality>
to the UC&R. Issue-38 is now closed.

Regards,
Frans

On 6 July 2016 at 13:03, Frans Knibbe <frans.knibbe@geodan.nl> wrote:

> 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
>>
>>
>>
>>
>