Linked Map
The Linked Map team is willing receive feedback on the results of the project. This project is a short term project (less than 1 year) and it is part of the larger FP7 project PlanetData. Linked Map address the development of a standard WMS that, at the same time, is a LD node offering read/write access to geographic knowledge. This vision is applied in a challenging scenario: the use of crowdsourcing techniques to improve the quality of the automatic integration of a National Map with existing VGI data.
Up to date we have developed:
- A transparent semantic proxy for WMS 1.3.0 (deliverable D17.1)
- Transformation into RDF of a National Map (BCN/BTN25 provided by IGN.es) and a VGI dataset (a portion of OSM) (deliverable D16.3)
- Large scale alignment of both datasets using only name, type and location properties (deliverable D16.3)
- Annotation of the resulting RDF datasets at feature level with W3C PROV ontology (deliverable D16.1 and implementation D16.3)
- A web application that enables a basic crowdsourced approach to the quality assessment of mappings and data (deliverable D18.1). The early beta version is available at http://linkedmap.unizar.es/crowdsourcing-platform/
Deliverables are available for download at http://planet-data-wiki.sti2.at/web/Deliverables and http://linkedmap.unizar.es/deliverables/
We would very appreciate your comments.
Pingback: FYI: Linked Map | Places Community Group
Developing this is a really good idea! If this works, we will have a very important link between ISO 191** and Linked Data. I sincerely hope the team will reach their goals!
If I understand correctly, to make use of such a data resource one would only need two URIs:
1) The (Linked Data) URI of the dataset, which in turn can supply other URIs, like the SPARQL endpoint.
2) The WMS URI.
Are those URIs already available?
Is it feasible to link from the WMS to the LD node and vice versa, using non-custom properties?
Good luck,
Frans
Not exactly. We are using Web Links (RFC 5899) and content negotiation for bidirectional linking of ISO 1919** and Linked Data resources. For example URI http://example.com/service?service=WMS&request=GetCapabilities is a WMS KVP request that returns the service document. With the help of Web Links we add a header pointing to a description of the resource (the service) in RDF. With content negotiation (e.g. text/turtle) we perform a 303 redirect to the description of the resource in RDF. Both are transparent for non semantic web clients, and they do not require to pollute the service metadata document with non standard annotations.
This is not only applied to GetCapabilities but also to GetMap and GetFeatureInfo. A client may request a map using GetMap. Then, the client wants a machine processable description of the resource. Then he can request again a GetMap with content negotiation or examine response headers for a Web Link to follow. The dereferenced GetMap request is routed to a URI that triggers a GeoSPARQL request that returns relevant features in the dataset described in RDF related to the GetMap request. In our experiment, these are features from a dataset rendered in the map that have been mapped to another dataset (OpenStreetMap). Note that the returned data includes a Web Link header and a RDF link to the original WMS request. So the bridge is bidirectional. That is, a semantic web client may navigate to the image (Get Map request) that describes a resource.
URIs are available (e.g. data is available here http://linkedmap.unizar.es/datasets/) but we are finishing the project and we are conducting some experiments. We plan to release a showcase with examples after the end of the project in September that should be more usable for testing that the current infrastructure.
Javier
(assuming my true identity now, forgot to log in when I posted the first reply)
Using Web Linking as a means to link the two seems a very smart idea! Frankly, I did not know that a thing like Web Linking exists 🙂 But I have just read about it, fortunately the concept seems simple enough.
I hope I have time to play around with the data after the showcase is up, and I hope many others will provide feedback too.
I still have some questions, but I assume just trying things will answer most.
OK, just one quick question: Let’s say I have the URI of a geographical feature, or the URI of its geometry. Could I request a map image of that feature just by using conneg? If so, what would be the content type to use?
That’s the idea. But, how the client can discover the content types. This is a possible procedure.
1. Client performs a HEAD request to the LD server
2. The LD server returns the response that is identical to a GET response without the message-body. The response contains Web Links to itself that hint the content types available with the parameter “type” (see point 5.4 of RFC 5899).
3. Client lookups for a web link with an image type and then conneg the image.
4. Finally, the LD server forwards with a 303 to the WMS or perform a proxy request to the WMS on behalf of the client.
In addition, it is possible to use a relation type that means that the links point to a preferred version of the resource (e.g. canonical – see IANA registry http://www.iana.org/assignments/link-relations/link-relations.xhtml ) because the preferred version is the map as image. In such scenario, the client should restrict the search to weblinks of such relation type, and then select the link with an appropriate image format (pgn, tiff, jpeg).
Note that the above only works if the LD server has metadata about the image formats supported by the server. We do that by using the capabilities of the WMS as configuration source for the LD node.