- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Sun, 7 Sep 2014 12:19:03 -0700
- To: <public-locadd@w3.org>
I would also be in favor of not using global domain and range restrictions. Best, Krzysztof On 09/06/2014 06:05 PM, Andrea Perego wrote: > 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/ > -- Krzysztof Janowicz Geography Department, University of California, Santa Barbara 4830 Ellison Hall, Santa Barbara, CA 93106-4060 Email: jano@geog.ucsb.edu Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Sunday, 7 September 2014 19:19:40 UTC