Reporting AS

[dret]

this is a first attempt to define an AS activity that represents the fact that a report has been generated for somebody who completed an exercise. this is basically saying "a piece of software generated a report for a person, there's noting critical in there, and the resulting object is a report of elevated HR, which contains 4 episodes of elevated HR".

{
    "published": "2015-01-13T13:14:55Z",
    "startTime": "2015-01-11T09:00:00Z",
    "endTime": "2015-01-12T09:00:00Z",
    "status": "completed",
    "actor": {
      "objectType" : "software",
      "displayName": "The HR Analyzer"
    },
    "verb": "analyzed",
    "subject": {
      "objectType" : "person",
      "id" : "http://dret.net/netdret/",
      "displayName" : "Erik Wilde"
    },
    "criticality" : "low",
    "object" : {
      "objectType" : "elevatedHRreport",
      "elevatedHRepisodes": "4",
      "title": "HR episodes for January 11, 2015",
      "url": "http://www.heartrate.com/report/438782763587.csv"
      }
    }
  }

let's first discuss what else we might want in there, or what we might not want in there. after that we can talk about how we want those things to be represented, and made open and extensible.
ideally, we want this example to also represent lab results such as blood tests, so that all of the reporting can be done in a uniform way. for that example, the resulting object then would be different: it would be a lab report with, for example, blood test results.

[smnmyr]

Thanks Erik. So the idea is that anyone interested in your elevatedHR would:

1. Create a filter for subject.id = http://dret.net/netdret and object.objectType = elevatedHRreport
2. Receive the AS and unpack the objects
3. Dereference the object url and parse the resource to yield the 4 distinct events
4. Display this data

I think we don't need the criticality field. For the future, I suggest an additional provenance field (or "derivedFrom") that points to the data used by the "The HR Analyzer" to derive this report.

Finally, I think we're abusing the startTime and endTime fields here - shouldn't those in this case tell us when the analysis started/ended rather than holding kind-of-tacit information about the underlying data?

[dret]

yup, i like the 1/2/3/4 steps. also, 3 and 4 could depend on whether the object seems to be worth the effort. if you only want to display critical/interesting episodes, then maybe the AS metadata allows you to ignore some. i just made this up, but it might be an interesting use case.
criticality was simply to highlight our ability to include metadata that we might think is interesting for filters and processors. if we don't need yes, let's leave it out.
imho it is not interesting when the analysis process started and terminated (that's as interesting as knowing how long the upload process from my garmin took). the timestamps in my example are about when the analyzed dataset starts and end. the interesting aspect about an analysis (and i don'l like this verb but couldn't think of a better one) is which time interval is covered by that analysis (if the analysis spans an interval).
iff we wanted to build something on ASbase where we measured the performance of analysis steps, then might might also want them to include information for resource consumption and runtime, but other than that i think we should focus on the fact that the analytics (may) span a certain time interval (not true for lab report, of course, which are just published at some point with no startTime or endTime).

[smnmyr]

Agreed.

On Tue, Jan 13, 2015 at 7:19 PM, Erik Wilde notifications@github.com
wrote:

yup, i like the 1/2/3/4 steps. also, 3 and 4 could depend on whether the
object seems to be worth the effort. if you only want to display
critical/interesting episodes, then maybe the AS metadata allows you to
ignore some. i just made this up, but it might be an interesting use case.
criticality was simply to highlight our ability to include metadata that
we might think is interesting for filters and processors. if we don't need
yes, let's leave it out.
imho it is not interesting when the analysis process started and
terminated (that's as interesting as knowing how long the upload process
from my garmin took). the timestamps in my example are about when the
analyzed dataset starts and end. the interesting aspect about an analysis
(and i don'l like this verb but couldn't think of a better one) is which
time interval is covered by that analysis (if the analysis spans an
interval).
iff we wanted to build something on ASbase where we measured the
performance of analysis steps, then might might also want them to include
information for resource consumption and runtime, but other than that i
think we should focus on the fact that the analytics (may) span a certain
time interval (not true for lab report, of course, which are just published
at some point with no startTime or endTime).

—
Reply to this email directly or view it on GitHub
#6 (comment).

[dret]

very good then. let's wait for more team feedback. and maybe the AS WG has some feedback on how to best model the "source" information other than with "subject" (which i just made up). james snell said they don't have a construct for it now, so we can build our own model of it (like the proposed "subject" or maybe something a bit more sophisticated), or try to build AS WG consensus around it.