How to represent taking a measurement?

[Evan Prodromou]

There are a few interesting cases for taking a measurement.

1. A human being weighing himself or herself.
2. A process measuring the load on a server.
3. A thermometer measures the current ambient temperature.

I'm thinking that the structure could be something like:

{

"actor": { "objectType": "device", "id": "http://thermometer.example/4512", "displayName": "Thermometer #4512" },

"verb": "measure",

"object": { "objectType": "place", "id": "http://gazetteer.example/montreal", "displayName": "Montreal" },

"result": {"objectType": "temperature", "value": 19", "units": "C" }

          }

I could also see doing this without a measuring actor:

{

"actor": { "objectType": "place", "id": "http://gazetteer.example/montreal", "displayName": "Montreal" },

"verb": "has-temperature",

"object": {"objectType": "temperature", "value": 19", "units": "C" }

          }

I think the first format is more precise but sometimes you may just want to know how hot it is in Montreal without specifying exactly who told you that.

Any opinions? I'm working on a weigh-in app and a weather app for pump.io, so I thought it'd be interesting to speak here.

-Evan

[Melvin Carvalho]

On 23 May 2013 17:26, Evan Prodromou <evan.pr...@gmail.com> wrote:

There are a few interesting cases for taking a measurement.

1. A human being weighing himself or herself.
2. A process measuring the load on a server.
3. A thermometer measures the current ambient temperature.

Quite an important use case as it also includes money in a virtual wallet.

You need a quantity and a unit (denomination)

So the quantity can be an int/float, or worst case scenario a string

The unit is interesting

You either need a registry of units, e.g. "C" in your case, or you use a fully qualified URL.  URLs are more verbose but registries need to be agreed and maintained. 

 

I'm thinking that the structure could be something like:

{

"actor": { "objectType": "device", "id": "http://thermometer.example/4512", "displayName": "Thermometer #4512" },

"verb": "measure",

"object": { "objectType": "place", "id": "http://gazetteer.example/montreal", "displayName": "Montreal" },

"result": {"objectType": "temperature", "value": 19", "units": "C" }

          }

id is probably a mistake here in both cases, as slash urls are documents and to be a document and a device at the same time is not future proofed (see "cool uris dont change") ... but the web of course will tolerate this

as above you need a registry of objectTypes ie "device", "place", 'temperature" for this strategy

 

I could also see doing this without a measuring actor:

{

"actor": { "objectType": "place", "id": "http://gazetteer.example/montreal", "displayName": "Montreal" },

"verb": "has-temperature",

"object": {"objectType": "temperature", "value": 19", "units": "C" }

          }

this modelling style I like much better than the first one (ie not including result)

 

I think the first format is more precise but sometimes you may just want to know how hot it is in Montreal without specifying exactly who told you that.

Any opinions? I'm working on a weigh-in app and a weather app for pump.io, so I thought it'd be interesting to speak here.

Thanks for bringing up the use case, it's an important one.  Adding these new terms as literals I think will require documentation and maintenance, so that clients can understand what they mean.  Traditionally it's customary to use namespaced urls where possible as this would allow A) self documenting data and B) increased ineroperability for pump.io

just my 2 cents ...

 

-Evan

--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To unsubscribe from this group and stop receiving emails from it, send an email to activity-strea...@googlegroups.com.
To post to this group, send email to activity...@googlegroups.com.
Visit this group at http://groups.google.com/group/activity-streams?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Christopher Lakey]

I just want to throw out another term that complements measure and that is "observe". 

It makes more sense to observe a state (i.e on or off) rather than measure it. Observing a measurement also makes sense. This actor is the observer and the object can provide additional metadata about the observation. 

It's been a while since I have read it, but there is an OGC / ISO specification describing a model for observations and measurements that some might find interesting to read. 

http://www.opengeospatial.org/standards/om

-Christopher

[James M Snell]

I agree that "observe" is likely a far more appropriate verb here...

{

"actor": {
"objectType": "device",
"id": "http://thermometer.example/4512",
"displayName": "Thermometer #4512" },

"verb": "observe",
"object": {
"objectType": "temperature",
"value": 19", "units": "C",
"location": {

[Laurent-Walter Goix]

Indeed an extremely interesting use case as it can start encompassing context/sensor networks and many smart environments such as home etc. as objects are becoming smarter the AS format can demonstrate its flexibility of use for the social web of things...
Given this I would support having units as Uris to facilitate understanding and uniqueness. Simple tokens may become more and more ambiguous and would anyway need some explanation/registry, also given they're pretty much specific to some objectTypes.
As actors publishing their observations (nice verb) "device" is probably very generic and could work but "sensor" or more appropriate types may provide richer semantics.
I can understand the rationale for an "has-temperature" case (what I would call a "passive" activity wrt to the observation action itself) but I find the specific verb very limited in terms of flexibility as types of measurements/observations increase (would basically require a dual passive mode verb,which is counter performing IMO). Something like "has" (too generic?) or "has-observation/measure" could be defined once and apply to many use cases.

Walter

[Bob Wyman]

It would be good if you could include a "precision" value, using the same units as the value. In theory, precision will often be asymmetric, but unless you're really getting into scientific measurements, specifying that the value was to be understood as a +/- adjustment would be sufficient. (i.e. Temperature is 20 degrees Celsius +/- 1 degree.)

"device" might be too restricting in that not all measurements are made with a device. Consider instead, a "method" that would contain a string describing the method or device used to perform the measurement. If "observation" was a permitted "method," then you wouldn't need to handle it as a special case (as others have suggested.) One assumes that a registry of method identifiers would be established at some point for those cases where it really mattered. 

bob wyman

-Evan

[James M Snell]

I would consider "method" to be a property of the "measurement"...
somewhat independent of the "observer"/"actor".

e.g.

{
"actor": {
"objectType": "sensor",
"id": "http://sensor.example/4512",
"displayName": "Sensor #4512" },
"verb": "observe",

"object": {
"objectType": "temperature",
"value": 19",

"units": "C",
"method": "......",
"location": {