Open 6a6d74 opened 3 years ago
Is there any interest from the SDW-IG in developing the "problem description" document?
@BillSwirrl - at the SDW-IG meeting in May you said you'd try to collect your thoughts on this subject. Did you find any worth sharing? Thanks.
Here's the discussion from the SDW-IG plenary call, 22 Jul 2021 (minutes):
jtandy: The issue summarises a limitation of the web in its current form. It would be good for this group to produce a note on the problem and options to solve it
roba: We see a need for this in the OGC definition server, because of the need to distinguish different views of resources … there are various ad hoc solutions out there, but the web itself doesn't work that well for a coherent 'web of data' that has any scalability … There is definitely a problem. Maybe not a big driver on the interoperability
bill: have been trying to tackle aspects of this data interop problem, it comes up all over the place. … I worry there would not be a community ready to consume a structured mechanism for this … I recognize the importance of this problem
jtandy: so the community is not mature enough for solutions that might work
bill: yes. Not saying we shouldn't do it, but something to think about
Summary. This remains a big challenge, but there's little appetite to chew on this problem.
Recommendation - we include this challenge in the broader "SDW 2022" review that aims to articulate the broader challenges about use of geo data on the web, and what might be done about it. See discussion here: Issue 1271
Problem summary:
The HTTP 303 redirect that's commonly used to relate real-world features to their digital counterpart(s) is a hack. There are no semantics conveyed - nothing to explain what information is conveyed by the resource you're being redirected to. But, it's the best of a bad bunch of options.
We often have many digital counterparts for a given real-world feature - each conveying different information, different semantics.
We typically use Content Negotiation (conneg) when resolving the URL for an information resource. That's fine if you want to choose GeoJSON instead of GML (e.g. choose the media type), but that doesn't help with semantics. There are typically many digital counterparts to a real-world object, each conveying different types of information.
Rob Atkinson (& co.) have long been working on the use "profiles" to characterise and describe the semantics of a domain-specific content model (?) that's encoded in a widely used data format.
But we can't use conneg to select by profile.
Finally, we still have issues around use of the canonical URI for the real-world feature. We often see people using the URL of the digital counterpart in their applications when they're intending to talk about the real-world thing itself.
So this often means that we're not sure that we're talking about the same thing or not. We need to make sure that applications are using the stable, canonical identifier to talk about a given resource.
An unsolved challenge is determining who's talking about (i.e. publishing information about) a given resource. We sometimes refer to this as "in-bound links". Search engines are beginning to use structured markup in information resources to pull together all information relating to a specific resource into a single search result. But there's no transparent infrastructure in place to support this kind of aggregation.
These challenges are commonly seen in the Augmented Reality (AR) world.
Given all of the above, information discovery and use tends to work in practice. Albeit with some offline/out-of-band schema sharing to provide the semantics for the information.
Proposals to remedy these challenges include:
Next steps:
Background information:
This topic has been discussed at two SDW-IG plenary calls: