Re: A proposal for two additional properties for LOCN

somebody wrote this I can't figure out who ...

> If we only consider cartesian spatial reference systems, it could be http://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#LengthUnit and http://qudt.org/schema/qudt#AngleUnit?

In any case, it is "apparently" true for humans, but it is not true for photons.

http://www.gandraxa.com/length_of_day.xml
The "Twilight" calculation amounts to adding Atmospheric Refraction twice in the same direction - Twilight is a angular shift increasing clockwise.

At the mean value, Noon/Equator there is a zero width "pole".  The poles we named (North and South) have polar angles 1/2 the size of the "poles" we don't think to much about (The Prime Meridian and the International Date Line).  The "shift" is not a Chemical Shift (which identifies a Chemical), but it can be computed for the difference in Range (-90 to 90 Latitude), (-180 to 180 Longitude).  It is a very tiny number, and it has comprehension problems - I don't know what it "means" - but it does not have computation problems.  A "Polar" curve fit works nicely.

--Gannon

--Gannon 





--------------------------------------------
On Tue, 9/16/14, Ghislain Atemezing <auguste.atemezing@eurecom.fr> wrote:

 Subject: Re: A proposal for two additional properties for LOCN
 To: "frans.knibbe@geodan.nl Geodan" <frans.knibbe@geodan.nl>
 Cc: "public-locadd@w3.org Mailing list" <public-locadd@w3.org>
 Date: Tuesday, September 16, 2014, 10:38 AM
 
 
 
 
 Le 16 sept. 2014 à 16:42, Frans
 Knibbe | Geodan <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
  
 If we only consider
 cartesian spatial reference systems, it could be http://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#LengthUnit and http://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>
 .
 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
 ?
 Cheers,Ghislain

Received on Monday, 22 September 2014 22:50:38 UTC