Re: A proposal for two additional properties for LOCN

Hi, Frans.

My comments inline.

> [snip]
>
>> 1. For both properties, I wouldn't specify their domain and range, but
>> I would add a usage note. I would also define them only as
>> rdf:Property's, at least for the moment.
>
> For now I have removed the domain restrictions from the wiki page (they are
> struck through).  I left the range specifications in place for now, pending
> further discussion.

Thanks, Frans.

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

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

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/

Received on Sunday, 7 September 2014 01:05:51 UTC