Re: A proposal for two additional properties for LOCN

On 2014-09-07 3:05, Andrea Perego wrote:
> Hi, Frans.
>
> My comments inline.
Mine are too.

>
> [snip]
>> 2. Should these properties be made more generic, so that they can be
>> used also to specify the temporal ref system / resolution?
>>
>> This relates back to the space and time talk.  Was there a clear conclusion
>> to be drawn from that?
>>
>> My opinion still is that there is no reason to handle space and time in the
>> same vocabulary. I think it is better if concepts for location and concepts
>> for time are developed in different vocabularies, overseen by the respective
>> domain experts.  It is true that publishers of location data can have a
>> great need of temporal expressiveness and that there is a current lack of a
>> good time ontology, but still I think the concerns are best left separate.
> I was thinking that, if a property allows specifying resolution as a
> pair "number + unit of measure", I can potentially used it also with
> units of measure not related to space. So, to rephrase my question,
> should we a priori prevent this?
>
> Note that this is not meant to be a rhetorical question. There may
> well be reasons to have specific properties for spatial and temporal
> resolution - e.g., because of reasons similar to those behind the
> definition of dct:coverage, dct:spatial and dct:temporal, explained by
> Makx [1].

I have the feeling that in a vocabulary about location and addresses a 
concept about another subject, or a more general subject, should not be 
introduced. I think that would interfere with the modularity of the 
semweb.  But, as always, I am willing to be convinced otherwise :-)

It could be that there is a need to have a general concept of resolution 
(in any dimension or combination of dimensions), but I have the feeling 
such a definition should then be housed in a more general or higher 
level ontology. By the way, I would not be surprised if the concept of 
resolution can be found to apply to other things than space and time.

One line Makx's explanation struck me as a warning against involving 
time in the locn vocabulary: /"I also need to note that some of the more 
'semantically oriented' people in the DCMI community around 2003-2004 
expressed a strong opinion that the lumping together of two very 
different dimensions had been a big mistake, because it made automated 
processing very hard"/

I did wonder if it would be a good idea to enable having a global 
spatial resolution and (as subproperties for instance) separate 
resolutions for:

  * the X direction (for cartesian reference systems)
  * the Y direction (for cartesian reference systems)
  * Longitude (for geographic reference systems)
  * Latitude (for geographic reference systems)
  * Elevation (for cartesian and geographic reference systems)



>
>>> 3. For (spatial) resolution, I think we should find a way to specify
>>> arbitrary units of measure - I wouldn't exclude a priori the
>>> possibility of encoding them as literals (e.g., 5m, 100x100px).
>> If the spatial resolution is a number, some very convenient ways of using it
>> can be thought of. For example:
>>
>> "Give me the geometry of the city of Paris with the highest spatial
>> resolution"
>> "Give me all datasets about vegetation in Poland with a spatial resolution
>> between 100 and 500 meters"
>>
>> Now if the range of spatialResolution is left unspecified, wouldn't that
>> discourage this kind of usage? And wouldn't it discourage data publishers to
>> specify the spatial resolution is a useful way?
>> If the spatialResolution is not a number with a specified unit (meters), I
>> am afraid that it can not be used effectively for automated data processing,
>> that it would always require a human to make sense of the value.
> I see the point, but I'm still not sure the range should default to a
> given unit of measure. People are not using just the metric system,
> and some software agents may be optimized for using metres, feet, etc.
>
> For these reasons, I'd rather specify it explicitly, either by using
> an approach similar to the one of GoodRelations, mentioned by Bart
> [2], or by using a syntax encoding scheme, as the one used for CSSs
> [3] - provided that a use case exists for this solution.

A conversion from feet or some other legacy unit of distance to meter 
(the SI unit that everyone should use) is trivial, so I in that respect 
I think there is more lost than gained if the property is made more 
complex (value + unit instead of just value). But I have just realized 
that a conversion from degrees (as used in geographic coordinate 
systems) to meters is less trivial, because it could be dependent on 
location. I can see the need for using a value + unit scheme for those 
cases.

So now I tend to agree that using a value and a unit to specify the 
spatial resolution could be the best solution. Perhaps we can make the 
unit default to meter, if it is not specified?

In some experiments I had the need to denote particular units of 
measurement. I used the QUDT vocabulary (http://qudt.org) for that. Is 
that a good (the best?) ontology for units to be used in this case? I 
think it is preferable to let the unit be a resource instead of a string.

Greetings,
Frans

>
> Andrea
>
> ----
> [1]https://www.w3.org/community/locadd/wiki/Space_and_Time#Discussion_4
> [2]http://lists.w3.org/Archives/Public/public-locadd/2014Sep/0013.html
> [3]http://www.w3.org/TR/css3-values/


------------------------------------------------------------------------
Frans Knibbe
Geodan
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl <http://www.geodan.nl> | disclaimer 
<http://www.geodan.nl/disclaimer>
------------------------------------------------------------------------