RE: Addition to use case & new req?

Yes, I will email you separately with the contact details. Sander was in the WG breakout session on Wednesday 10 feb by the way, and explained his point pretty well. See the minutes… https://www.w3.org/2016/02/10-sdw-minutes


Van: Frans Knibbe [mailto:frans.knibbe@geodan.nl]
Verzonden: vrijdag 19 februari 2016 16:20
Aan: Linda van den Brink
CC: SDW WG (public-sdw-wg@w3.org)
Onderwerp: Re: Addition to use case & new req?

Hi Linda,

There is an action on me now too: action-136<https://www.w3.org/2015/spatial/track/actions/136>. Would it be possible for me to get in contact with the submitters of the use case (Nic Roest and Sander Stolk) in order to find out in which way the case is about real world things?

Regards,
Frans

2016-02-04 10:49 GMT+01:00 Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>>:
The discussion seems to have halted a bit, so I have just created a new issue in the tracker, so we won't forget about this: https://www.w3.org/2015/spatial/track/issues/38


Regards,
Frans


2016-01-26 11:09 GMT+01:00 Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>>:
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<mailto: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<mailto: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<mailto: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<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