Discussion on Features, information resources and real-world Things is unclear.

[6a6d74]

In point (11) of his email to the WG @fransie says:

6.1: Is the discussion about features, information resources and real world things really necessary? I find it slightly confusing and I can imagine other will too. Why not just say that if you want spatial data to be referenceable on the web you need to use URIs? Just that makes a lot of sense and could be less confusing.

[6a6d74]

My response:

@lvdbrink has attempted to capture the discussion that occurred during the Sapporo F2F; this discussion certainly had value at the time. I'm wary of reducing the context to the single statement you suggest but agree that it's not currently straight forward. We may also want to talk about the difference between Features (information resources) and Spatial Things (the resources described by the information) and the fact that in the end, the distinction is often not helpful.

[6a6d74]

@andrea-perego states in point (3) of his email to the WG:

The notion of "feature" is clearly defined in Section 6.1 of the BP as an information resource describing a real-world thing with (geo)spatial characteristics. However, the actual semantics of the
notion of "SpatialThing", as used in the BP, is ambiguous. Is a spatial thing just a real-world thing with spatial characteristics? Or it can also be an information resource with spatial characteristics (e.g., what
is represented in an image file)? And, if this is the case, can a feature be a spatial thing?

@fransie responds:

Would it be possible to skip trying to define features and spatial things altogether? I think it only leads to confusion (and we all know that ultimately leads to the Dark Side). Trying to define what things, features, real world objects, etc. are can lead to deep philosophical abysses and put people off. Is Atlantis a spatial thing? Am I a spatial thing? Are my thoughts spatial things? Is a word in a book that I am reading a spatial thing? Given any definition, one can always come up with examples that cause mental friction.

Of course we do need some way to let the reader know the scope of our subject, but probably the reader already has an idea of what spatial data are and that idea is probably right. A simple definition that we could use is: Spatial data are any kind of data where location matters. Or in other words: data are spatial if you want them to be spatial.

Our subject is data. So we don't have to be concerned with real world (whatever that is) concepts that are described by data. That's a relief! Within the scope of data, any data can be spatial. What makes it spatial is that location matters and should be recorded. Data about a person, a lighthouse, a word in a text, etc. only is spatial if its location (with respect to a spatial reference system or with respect to something else) matters. If that is the case, people should read our BP document and put it in to practice.

@andrea-perego:

Fine. But then we shouldn't use at all those terms.

@fransie:

Yes (+1). If we don't use the terms we do not have to define them. A win-win situation :-)

[lvdbrink]

We should definitely add a description of what we mean by 'spatial thing'. But I prefer to retain the explanation around features, information resources and spatial things. See also my response on the mailing list.

[6a6d74]

In his email to the WG Clemens says:

I think that has been raised by others, too, but right now I see at least "spatial data", "spatial information", "geospatial data", "geographic information" and "geospatial information". Probably we need only two of those, although from the document it is also unclear that there is a distinction between "spatial" and "geospatial" and what that distinction is.

[lvdbrink]

See also this thread. there's still an open issue about identifier assignment. Do we recommend to assign different identifiers to spatial things and to information resources about those things?

We seem to be close to consensus: use of the same identifier for both i.e. using the information resource identifier as indirect identifier for the spatial thing, is ok. Metadata about the information resource goes in the metadata.

[6a6d74]

We agreed at TPAC-2016 that most of the time using a single identifier for spatial thing and page/document resource is both simpler to implement and better meets the expectations of end users.

As such, there is no obligation to distinguish between the spatial thing and the page/document unless your application requires this.

The BP doc is updated to accordingly (see this commit). The doc also states that while there is a cost to this conflation, problems can be mitigated by avoiding making statements that confuse spatial thing and the page/document, such as “Uluru is available in JSON format”; e.g.

<http://sws.geonames.org/7645281> dc:hasFormat ex:json .

[6a6d74]

@lvdbrink says:

I discussed the WG’s thoughts on indirect identifiers a while back with some people from the Platform Linked Data Nederland, who were a little uncomfortable with this. They feel we shouldn’t recommend this as best practice while the TAG says we should use 303 https://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html and asked me to bring this back to the WG.

I myself wouldn’t mind if we suggest the possibility but also explain when distinguishing between thing and information resource is important.

So I'm re-opening this issue and will add a reference back into the BP document.

[6a6d74]

@philarcher1 recalls TimBL's comment from the Sapporo TPAC where he said, about vcard, no-one worries about /id and /doc anymore.

[liekeverhelst]

I agree with @6a6d74 . @lvdbrink the TAG recommendation is 12 years old...a lot has happened since. I see people are confused & making mistakes with /doc and /id (e.g. making RDF links to a /doc identifier !) . Also now there are LD viewers such as lodview that provide elegant & configurable solutions that do not need URIs to have a particular outline. In this case the viewer app takes care of correct conneg.

[lvdbrink]

Discussed during face to face meeting Delft and have consensus within the group that this issue can be closed and ref to it can be removed from the doc. This will be done in the next release. See minutes