Re: Addition to use case & new req?

Yes, there is often a need to integrate data that are modelled in different
ways. But that is a general requirement, I think. Not something typically
spatial. Is location really necessary or the best way to make clear that
different staments relate to the same thing?

 I also don't see how the real world feature plays a role here. This seems
to be all about different models, different abstractions in data.

Regards,
Frans



2016-01-25 19:50 GMT+01:00 Joshua Lieberman <jlieberman@tumblingwalls.com>:

> This can be a very helpful use case as it shows a situation where not only
> multiple datasets but multiple models are connected by common geography. We
> had discussed that connecting different datasets to the same real world
> feature as representing an opportunity for integration, e.g. semantic
> consistency. In the cases of the perspectives described below, they are
> cognitively different real world features being recognized for the same
> building, which is quite common in both engineering and asset management.
> There is the “real” feature that you can see and touch, and multiple
> “formal” features such as declared assets or as-builts. It is important to
> recognize the coincidence of data about multiple features because
> integration that doesn’t recognize that situation may go very wrong. For
> example, logical statements about a building feature that distinguish walls
> and windows may appropriately be appropriately  inconsistent with
> statements about a wind obstacle where walls and windows are not
> distinguished. Without identification of both the location that datasets
> pertain to, “and” what recognized feature they describe, such errors will
> be difficult or impossible to avoid.
>
> Josh
>
>
> On Jan 25, 2016, at 8:06 AM, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>
> Hello Linda,
>
> For resolving Githubissue 208 <https://github.com/w3c/sdw/issues/208> it
> would be good to try to find an example of a practical case in which
> definitions of concepts like 'real world phenomenon' or 'spatial thing'
> really matter. Then we would have something that can refute the hypothesis
> that those definitions are not needed in the BP document. But so far I
> don't see that in this use case. It looks to me that it is about trying to
> combine data from different domain perspectives, but perhaps I am missing
> something
>
> Three perspectives are described, a real-world perspective, a chart
> perspective and a format perspective. In all cases it is about providing
> data about something, an office building for example. Those data could be
> combined in a single data set that gives a URI to the building and provides
> data according to different domain models (vocabularies). Or the data could
> be kept separate, in which appropriate semantics can be used to link the
> different representations. But all perspectives are about data
> representations, right? So in what sense does the real physical world ever
> come in to play?
>
> Regards,
>
> Frans
>
>
>
> 2016-01-25 10:33 GMT+01:00 Linda van den Brink <l.vandenbrink@geonovum.nl>
> :
>
>> Hi Frans, SDW WG members,
>>
>>
>>
>> People working in semantic modelling in the Dutch construction sector
>> have been telling me about a requirement they have for a relationship that
>> indicates one resource is a registration of another. I.e. one is the real
>> world thing, the other is a digital registration of (properties of) that
>> thing. Because we have an issue around this distinction between real world
>> thing and representation of that thing (
>> https://github.com/w3c/sdw/issues/208 ), I asked them to write their use
>> case down in more detail.
>>
>>
>>
>> We could merge this use case with
>> https://www.w3.org/TR/sdw-ucr/#BuildingInformationManagementAndDataSharing
>>
>>
>>
>> The use case text as sent to  me is below (thanks to Nic Roest and Sander
>> Stolk of http://www.semmtech.com):
>>
>>
>> Make different perspectives explicit for resources on the same (spatial)
>> subject
>>
>> In civil engineering and asset management settings, interdisciplinary
>> information exists alongside each other. Such information typically
>> overlaps and complement each other. Think of design information (CAD),
>> geospatial information (GIS), and information for systems engineering (SE).
>> These are produced by different pieces of software, and adhere to different
>> perspectives – although they are quite possibly on the same subject (e.g. a
>> specific office building or road).
>>
>> Problems arise when combining information on a single subject from
>> different perspectives, in an attempt to complement information from one
>> with that of another. As such, terminology is needed to capture that
>> resources may be about the same subject but follow different perspectives.
>> To illustrate we will touch on 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 aforementioned perspectives to capture information on the same office
>> building are by no means exhaustive. What they exemplify is that vastly
>> different perspectives of the world and its real-life objects exist.
>> Resources that are on 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 the above differences in perspective are not identified and made
>> explicit, an attempt at integrating information 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 is not currently open.
>>
>>
>>
>>
>>
>> Linda
>>
>>
>>
>
>
>