Re: Addition to use case & new req?

Hello all (and Phil in particular),

I got into contact with the people who contributed this scenario. As I
understand it, it is not so much about HTTPRange-14, as about how to link
many different representations of the same real world object to each other.
The same real world thing could be described in different data sets that
use different models and different perspectives. One set of data about a
thing could come from a GIS, the other from a CAD or BIM system. The
question is: how can be expressed that different web resources are
representations of the same thing (a house or a road for example)?

As I understand it, the thing itself does not have a URI, the problem is
how to relate the different resources that are representations of the
thing. Of the possibilities that immediately come to mind, owl:sameAs is
considered too strong (the representations have different attributes) and
rdfs:seeAlso is considered too weak (everything is related to everything
else in some way).  I have just suggested some predicates that seem to be
somewhere in the middle, but I don't know if they suffice:

umbel:isLike
<http://wiki.opensemanticframework.org/index.php/UMBEL_Vocabulary#isLike_Property>
bbccore:sameAs <http://www.bbc.co.uk/ontologies/coreconcepts#terms_sameAs>
http://schema.org/about

Admittedly this problem is not strictly spatial. The problem of how to
relate different data perspectives on the same thing is broader. But the
submitters of the use case feel that since the broader community (or the
W3C) have not been able to come up with a good solution for the problem
yet, a more focused community working with clear use cases could force a
solution and make it more broadly accepted afterward. Personally, as a
guardian of requirement scope, I would be hesitant for us taking that role.

@Phil: Are you aware of a general best practise or recommendation being
available for this problem? Could this be a topic for the Data on the Web
Working Group?

Regards,
Frans




2016-02-19 16:19 GMT+01:00 Frans Knibbe <frans.knibbe@geodan.nl>:

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