Re: A proposal for two additional properties for LOCN

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

Indeed. And the DWBP WG is also working on a vocabulary concerning
data quality and granularity that may contribute to this (e.g., by
recommending/defining how to specify the notion of "level of detail").

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

Probably (but Makx can correct me if I'm wrong) the point was that, in
that point in time, DC terms were used just with literals, and not
with class instances. In our case, the question is whether processing
would better be done at property level (:resolution vs
:spatialResolution) or rather at class level (:QuantityValue).

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

Do you have any specific use case in mind?

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

I agree, and maybe using QUDT is a good option.

Another solution is to use DBpedia, which has the advantage of being
multilingual and operated according to LD principles. However, it does
not cover all the units of measure included in QUDT.

Maybe, we can recommend both - this should be pretty safe, since QUDT
includes skos:exactMatch with the corresponding terms in DBpedia, when
available.

About defaulting to metres, I'm concerned about how this can be
implemented safely.

Andrea

Received on Wednesday, 10 September 2014 23:02:28 UTC