Re: More UCR comments

Hi Alejandro,

thanks for your responses. I have added my remarks inline, too. I have prefixed them with "CP:".


> On 09 Jun 2015, at 11:06, Alejandro Llaves <allaves@fi.upm.es> wrote:
> 
> Thanks for your comments, Clemens! Find my answers inline.
> 
> On 2 June 2015 at 22:54, Clemens Portele <portele@interactive-instruments.de <mailto:portele@interactive-instruments.de>> wrote:
> Dear Frans, Alejandro, all,
> 
> a few comments on the current draft - mainly from the background of the use case I have contributed. I understand that this will likely be too late for the current version, but hope that we can discuss them when we prepare the next version. If I should add them as issues or pull requests let me know. I have lost overview what the correct process is for which type of comment...
> 
> 
> Requirement 5.20 (linkability) states: "Spatial data on the Web should be linkable (by explicit relationships between different facts in different data sets), to other spatial data and to or from other types of data."
> 
> I did not find "fact" in the glossary. On the other hand it has "feature" and that is used in other requirements, too. I would therefore propose to change "facts" to "features".
> 
> Makes sense to me. Changed.

CP: Thanks

>  
> 
> Linkability is also relevant for links within a data set. I would therefore propose to change "different data sets" to "the same or different data sets".
> 
> I think we can remove then that part referring to data sets, since it does not mind whether features are linked between data sets or within the same data set. The req. description would remain like this: "Spatial data on the Web should be linkable (by explicit relationships between different features), to other spatial data and to or from other types of data."

CP: This would be fine with me.

> 
> 
> The use case 4.10 (publishing geospatial reference data) also discusses the need for a capability to establish implicit links by identifying properties in features that are typical candidates for joins. To reflect this I would propose to introduce another requirement like "Spatial data on the Web should identify the semantics of feature properties in a common way to enable joining other types of data with the spatial data. Note: The purpose of these joins is typically to georeference the other data."
> 
> There are two existing reqs., besides the linkability one, that could cover this situation. First, we have Georeference spatial data <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#GeoreferencedData>, that would address the typical cases for georeference links. Second, could the Reference external vocabularies <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#ReferenceExternalVocabularies> req. address the other cases? Let me know if you want to relate your UC to any of these reqs.

CP: I think this is different than those two although the first one may be related. 

However, I do not understand the "Georeferenced spatial data" requirement. Currently it states that "it should be possible to georeference spatial data". Isn’t that a given? The glossary does not define "georeference" nor does the UCR document, but what spatial data would not be georeferenced? Maybe the healthcare data that is also mentioned in the charter? I did a search through our emails, but did not find any discussion.

If this would state something like "it should be possible to georeference other data (by explicit links or joins with spatial data)", then this would be what I have proposed.

In this context there may also be overlap with the work of the Data on the Web WG. The have a related requirement:

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

Maybe we should open an issue or action to discuss with that WG the overlap. Maybe Sapporo would be a good opportunity for that.

The "Reference external vocabularies" requirement is less applicable as that is about referencing external vocabularies *from* spatial data and the requirement I am proposing is about making it easier to link/join other data to/with spatial data.


> 
> 
> Another aspect of use case 4.10 is that it should be possible to determine the spatial relation between features in different data sets. Req 5.45 (spatial operators) may address this - in which case it should be linked to 4.10. However, it is not entirely clear what "operators" are in this context. Is the idea that any API providing access to a spatial data set provides these spatial operators so that I can determine, for example, all spatial things in the dataset that 'intersect' in another data set? If yes, should this be made explicit, perhaps in a note?
> 
> 
> Yes, I will link your UC to the Spatial operators <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialOperators> req. I understand from the description of the req. that spatial operators are properties that define spatial relations between features. Is that enough for your UC? Have in mind that after the FPWD is announced, we will go on refining the document, so all these comments are very helpful.

CP: I was actually thinking more about ways to identify relations (that may then be stored as properties). For example, so that you can identify from a dataset the things that are around you without looping through each one of them. 

>  
> Finally, the requirement text of 5.56 is the same as in 5.55. This must be a copy&paste error.
> 
> Fixed. 

CP: Thanks.

Best regards,
Clemens

> 
> Thanks,
> Clemens
> 
> Cheers,
> Alejandro
> 
> -- 
> Alejandro Llaves
> Ontology Engineering Group (OEG)
> Artificial Intelligence Department
> Universidad Politécnica de Madrid
> Avda. Montepríncipe s/n
> Boadilla del Monte, 28660 Madrid, Spain
> 
> http://www.oeg-upm.net/index.php/phd/325-allaves <http://www.oeg-upm.net/index.php/phd/325-allaves> 
> 
> allaves@fi.upm.es <mailto:allaves@fi.upm.es>

Received on Tuesday, 9 June 2015 15:52:19 UTC