Re: Addition to use case & new req?

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