Re: A proposal for two additional properties for LOCN

On 2014-09-16 17:38, Ghislain Atemezing wrote:
>
>
> Le 16 sept. 2014 à 16:42, Frans Knibbe | Geodan 
> <frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>> a écrit :
>
>> Suppose we want to have something called spatial resolution. We want 
>> it to have a numerical value (e.g. "1.405"^^xsd:decimal) and a unit 
>> (e.g.http://qudt.org/vocab/unit#Meter). The unit can not be fixed, 
>> because we want to allow other appropriate units, like feet or 
>> radians. However, inappropriate units (like kilogram or volt) should 
>> not be allowed.
>>
>> I think the fact that we want to have a compound expression for 
>> spatial resolution (value + unit) means that a class needs to be 
>> introduced, locn:SpatialResolution for instance. Now I wonder if 
>> there is a nice class in QUDT of which this class could be a 
>> subclass, something from which follows that the spatial resolution 
>> has a number and a specififcation of a unit. 
> Maybe this class can help?! qudt:QuantityValue ? Better to look at 
> this namespace http://qudt.org/1.1/schema/OSG_quantity-(v1.1).ttl 
> <http://qudt.org/1.1/schema/OSG_quantity-%28v1.1%29.ttl>
>> If we only consider cartesian spatial reference systems, it could 
>> behttp://qudt.org/vocab/quantity#Length. But then it would not be 
>> possible to express the spatial resolution as a number of degrees or 
>> radians.
>>
>> Could or should we make use of a combination of 
>> http://qudt.org/schema/qudt#LengthUnitandhttp://qudt.org/schema/qudt#AngleUnit?
>
> Hi Frans,
> Let see I’ve understood your thoughts ;)
> We can use a restriction on the property that links ex:resource to a 
> locn:SpatialResolution.
> I call it locn:hasResolution below, and I put restrictions in the 
> range to only take into account quantity values that are length and 
> angle units. We can maybe also use owl:unionOf in the restriction ?
>
> ############### start here in Turtle##########
> PREFIX qudt: <http://qudt.org/1.1/schema/OSG_quantity-(v1.1).ttl 
> <http://qudt.org/1.1/schema/OSG_quantity-%28v1.1%29.ttl>> .
>
> locn:hasResolution a owl:ObjectProperty;
> rdfs:label "link to a spatial Resolution"@en;
> rdfs:domain locn:SpatialResolution;
> rdfs:range [a  owl:Class ;
> owl:intersectionOf
> (qudt:QuantityValue
>              [ a owl:Restriction;
>  owl:allValuesFrom qudt:AngleUnit, qudt:LengthUnit;  ## (*)
>  owl:onProperty qudt:unit
> ]
> )
> ];
>            .
>  ######### end here the sample #################
> (*) Maybe it is not allowed to use different classes with 
> owl:allValuesFrom. I need to check it out.
>
> WDYT ?
>
Being not even an amateur when it comes to OWL modelling, I am impressed 
that you have come up with this! And I am having a hard time grasping 
all implications of this model too. Which leads me to think that as OWL 
is harder on both human and machine reasoners, does it make sense to try 
to model this in RDFS only? The class locn:SpatialResolution could have 
two subclasses: locn:AngularSpatialResolution and 
locn:CartesianSpatialResolution (or they could have other names, as long 
as one is used for geographics (spherical) coordinate systems and the 
other for cartesian (projected) coordinate systems). The two specialized 
classes could have related properties (e.g. 
locn:angularSpatialResolution and locn:cartesianSpatialResolution) and 
have simple ranges (qudt:AngleUnit and qudt:LengthUnit). Although this 
introduces more classes, it could be a way of untangling a difficult matter.

Or maybe we should not try so hard to disallow non-distance units?

Greetings,
Frans


> Cheers,
> Ghislain


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