Re: Addition to use case & new req?

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