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

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