Re: My action regarding the Data on the Web best practices

Hi Frans,

thanks for your response and considerations. 

The answer whether the current requirement captures the issue, the answer is yes, if the requirement includes links from other data to spatial data (unclear from the wording in the requirement which is mainly about links *to* other data) and includes links that are not based on URIs.

Best regards,
Clemens

> On 15 Apr 2015, at 14:03, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
> 
> Hello Clemens,
> 
> (I realise that this is not a direct answer to your questions)
> 
> In the spreadsheet with use cases and requirements <https://docs.google.com/spreadsheets/d/1PSnpJYQDgsdgZgPJEfUU0EhVfgFFYGc1WL4xUX9Dunk/edit?usp=sharing> the following requirement can be found in the best practices sheet:
> 
> spatial data on the web should be linkable (by explicit relationships between different facts in different data sets), to other spatial data and to other types of data.
> 
> This requirement is already linked to the use case you contributed. Do you think this requirement adequately captures the problem you describe? 
> 
> Of course the next question then is: Do we consider this requirement to be in scope? I think it should be, for the following reasons:
> The SDWWG charter is about spatial data on the web, not about Linked Data, which would be a narrower scope. Whether or not Linked Data principles will be recommended as a best practice, it seems that there is a strong desire to be able to link spatial things. So this is a very important requirement and I think we should therefore address it ourselves. If this requirement is deferred to other working groups, we could lose a lot of usefulness to real world spatial problems. Of course this does not prohibit our recommendations to be based on recommendations from other working groups.
> Spatial data can form a special kind of link that other data types can not: spatial data can have topological relationships. In other words, the concept of linkage of entities could have a spatial aspect. And if it is spatial, it is in scope. 
> Regards,
> Frans
> 
> 
> 
> 2015-04-14 15:53 GMT+02:00 Clemens Portele <portele@interactive-instruments.de <mailto:portele@interactive-instruments.de>>:
> Dear all,
> 
> first of all my apologies for tomorrow.
> 
> In Barcelona we had a discussion in the Best Practices group related to the publishing geospatial reference data use case I had submitted (https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Publishing_geospatial_reference_data_.28Best_Practice.29 <https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Publishing_geospatial_reference_data_.28Best_Practice.29>).
> 
> The point of discussion was whether the a part of the use case has any spatial aspects to it or whether it is just like any other data on the web, and consequently it is out-of-scope for us but we have to rely on this being covered by the parallel Data on the Web Best Practice activity.
> 
> To recap, there were in particular two aspects. Assume that a cadastral agency wants to put its parcel geometries together with the well-known parcel identifier (not a URI, a local string identifier) on the web. Other datasets will (implicily) link to the cadastral parcel data by using the parcel identifiers. Assume that such a dataset, e.g. records of real estate sales, is available as a CSV file on the web, and that the provider of the data may not be interested in providing the data set in a web-friendly way with explicit links to the parcel location using URIs.
> 
> The two aspects discussed in Barcelona related to best practices are:
> a. Is there anything that the cadastral agency should/can do, to make it easy for others that have some data with parcel identifiers to join the data, i.e. to get location information for their data?
> b. How could the publisher of the real estate sale data help others that want to use the data to make the explicit link to the reference dataset so that they can get the location context of the data?
> 
> Other examples for such geospatial reference datasets are statistical units, postal codes, administrative units, etc.
> 
> So, the question was: does the Data on the Web Best Practice work address these issues? I took the action in Barcelona to have a look.
> 
> My conclusion is: maybe.
> 
> My source has been the use case/requirements document (http://www.w3.org/TR/dwbp-ucr <http://www.w3.org/TR/dwbp-ucr/#R-PersistentIdentification>) and the best practices draft (http://w3c.github.io/dwbp/bp.html <http://w3c.github.io/dwbp/bp.html>).
> 
> It was not always easy to understand, if these aspects are in-scope of a use case or not. As an aside, a surprising number of their use cases have a spatial component. Anyhow, I have then mainly looked at the requirements they have identified from the use cases. I have identified two requirements that might address the above:
> 
> http://www.w3.org/TR/dwbp-ucr/#R-DataEnrichment <http://www.w3.org/TR/dwbp-ucr/#R-DataEnrichment>
> "It should be possible to perform some data enrichment tasks in order to aggregate value to data, therefore providing more value for user applications and services."
> 
> http://www.w3.org/TR/dwbp-ucr/#R-GeographicalContext <http://www.w3.org/TR/dwbp-ucr/#R-GeographicalContext>
> "GeographicalContext (countries, regions, cities etc.) must be referred to consistently. GeographicalContext is a type of metadata, so all metadata requirements also apply here."
> 
> It is not clear, how they interpret these requirements and if they cover the requirements in our reference data use case. The current draft of the best practices document does not yet address these requirements. I also could not find any other part on the current best practices draft that addresses the requirements.
> 
> Maybe someone else has more information as I have noted that several from our group are also involved in the Data on the Web group.
> 
> Best regards,
> Clemens
> 
> 
> 
> -- 
> Frans Knibbe
> Geodan
> President Kennedylaan 1
> 1079 MB Amsterdam (NL)
> 
> T +31 (0)20 - 5711 347
> E frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>
> www.geodan.nl <http://www.geodan.nl/>
> disclaimer <http://www.geodan.nl/disclaimer>
>