Re: Request to review the Semantic Sensor Network Ontology

OK, that makes sense, Armin.

If typing the data for every result is inefficient, is there a sane way 
to indicate that the sosa:Sensor always reports its results in a given 
unit, and then make the range of sosa:hasSimpleResult xsd:float?

Phil

On 08/06/2017 09:10, Armin Haller wrote:
> We can make that recommendation in the examples. We included the sosa:hasSimpleResult property, among other reasons, for IoT use cases where the size of the annotations matter, i.e. if you use the ontology for runtime sensing applications where you have potentially millions of observations from a sensor and you would want to keep the payload minimal.
>
> On 8/6/17, 6:01 pm, "Phil Archer" <phila@w3.org> wrote:
>
>     Just a bit of clarification.
>
>     The sosa:hasResult property links to a sosa:Result class that takes
>     value and units as separate fields. This is in line with i18n comments
>     on Data on the Web Best Practices which are fully reflected at [1].
>     However, there is also a property sosa:hasSimpleResult that takes a
>     literal. With the DWBP experience in mind, I raised this as an issue
>     encouraging the authors to strongly recommend/insist that the value of
>     sosa:hasSimpleResult should be a typed literal thereby including making
>     the units explicit.
>
>     Phil
>
>     [1] https://www.w3.org/TR/dwbp/#possible-approach-to-implementation-13
>
>     On 08/06/2017 08:52, Francois Daoust wrote:
>     > Hello i18n folks,
>     >
>     > This is a request to review the Editor's Draft of the Semantic Sensor Network ontology:
>     >
>     > http://w3c.github.io/sdw/ssn/
>     >
>     > The specification is on its way to Candidate Recommendation. The Spatial Data on the Web Working Group does not believe that this ontology has i18n issues (with one exception noted below) and did not ask the i18n working group for review before today. My apologies.
>     >
>     > The ontology describes sensors and their observations, the involved procedures, the studied features of interest, the samples used to do so, and the observed properties, as well as actuators.
>     >
>     > The i18n issue that the group is aware of has to do with the Result class. That class separates actual values from units, using typed literals, which seems like the right thing to do. However, datatyping is not explicitly encouraged by the spec for the time being, and one of the examples in the spec currently uses a string without any datatype. This is being discussed in:
>     > https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jun/0023.html
>     >
>     > You may raise i18n issues on the group's GitHub repository, which already has "i18n-comments" and "i18n-tracking" labels. The Spatial Data on the Web Working Group is tight on schedule as it needs to finish its work by the end of June. Let us know if there's anything we can do to speed up the review. I went through the self-review checklist but did not see anything that directly applies to this specification.
>     >
>     > Thanks,
>     > Francois.
>     >
>
>     --
>
>
>     Phil Archer
>     Data Strategist, W3C
>     http://www.w3.org/
>
>     http://philarcher.org
>     +44 (0)7887 767755
>     @philarcher1
>
>

-- 


Phil Archer
Data Strategist, W3C
http://www.w3.org/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Thursday, 8 June 2017 09:10:33 UTC