Re: A notation for expressing frequency of data collection

Hello.

I agree that data should be human-readable, but it does not mean we 
should make everyone read in binary or RDF! I doubt very much that 
end-users would be reading the data directly. Instead, usually, there's 
an application middle-layer which takes the data and presents it in 
human-readable form according to context of environment and users. In 
the same vein that raw sensor data is not presented directly, but is 
instead ingested to produce some relevantly friendlier information.

Reducing this argument to human-readability for developers or 
technically proficient individuals, we can provide data where the 
"intent" is clear.

For the example, where collection frequency is "every hour", there are 
several ways of doing this.

Consider :DeviceOps as a processing action of type :Collect

1) hanging an annotation

:DeviceOps dpv:hasFrequency "hourly"@en .

2) using enumerated nodes

:Frequency a rdfs:Class .
:Hourly a :Frequency ; rdfs:label "hourly" .
:DeviceOps dpv:hasFrequency :Hourly .

3) using OWL-TIME

# My knowledge of OWL-TIME is limited
:DeviceOps dpv:hasFrequency [ time:hours "1"^^xsd:decimal . ] .

4) using XS duration

# Note discouragement of this: 
https://www.w3.org/TR/swbp-xsch-datatypes/#section-duration and that 
parsers may expect 'proper' durations
:DeviceOps dpv:hasFrequency "1H"^^xsd:duration .

*) Note that in all this, the term "hourly" is still ambiguous implying 
it happens once sometime within an hour or that it repeats with interval 
of 1hour. Whether this is acceptable or more precision is required is 
dependant on the context of use-case.


On 05/01/2021 12:44, Railean, Alexander wrote:
>> The range for hasFrequency shouldn't be hard-set. So one could use enums
> 
>> (instances of a class are a better design pattern than strings IMO) or
>> OWL-TIME or XSD or ints. Same for duration or location or other properties.
> I agree, but to make sure we're on the same page, I want to double-check 
> a thing.
> 
> The problem has to be seen from 2 perspectives:
> [a] machine
> [b] person
> 
> A computer wants classes and strongly typed entities that it can 
> quantify and compare. But a grandma buying a gadget for her beloved 
> nephew wants to see "every hour" rather than  
> `Frequency(unit=hour,value=1)`.
> 
> My understanding is that you operate at the [a] level, whereas I operate 
> at [b], the user-facing side.
> 
> 
> Both aspects are important and must go hand in hand. Otherwise we 
> might end up with many different "human representations" derived from 
> the same formal specification, because different teams interpreted it in 
> their own way.
> 
> Can you provide some actual examples of what your proposal might look 
> like, from an end-user's perspective?

-- 
---
Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin
https://harshp.com/

Received on Tuesday, 5 January 2021 15:10:50 UTC