Best ontology for subject/value/date triples in a logsheet?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Best ontology for subject/value/date triples in a logsheet?

This post has NOT been accepted by the mailing list yet.
We're working on a form/template combo that aims to stand as a logsheet that will replace a bunch of spreadsheets and stand as an audit-able data entry tool.  Would be used for reporting in a waste water treatment plant environment.

There's ~100 fields on a daily logsheet (a numbered article), and each value stands to have count/averages/max/min type information summarized monthly. To reduce complexity in the template definitions, we jumped to storing a subobject for each value as:
|Value=Result we got
|Date=Date entered
|Unit=units of measure}}

This really simplifies the query syntax when generating reports, but would see some significant duplication of stored properties (ie, that date would get stored 100 times, same with 'Unit', and the 'Label' would be in the subobject name already). A sheet would be generated every day.

I have this nagging feeling that using this 'Label' property idea to make it easier to query is essentially adding an unnecessary layer to what SMW does in the first place. The alternative is to create a property for every single field and associate a single date with the article on which to constrain queries.

So, my question is does it matter which path we take? Is one of them the least bad? (is there a middle ground?). In the past I've flip-flopped between creating scads of specific properties vs consolidating with subobjects.