Separation of "intrinsic" vs. "management" concerns

[GoogleCodeExporter]

Description of the issue

There are two main concerns mixed in the ontology: 

(i) "static" aspects (eg., intrinsic characteristics of the instruments or
its composition);

(ii) more "dynamic" aspects in particular related with data management
(eg., deployments, change of status of particular sensor instances). 

We need to keep a clear distinction of these concerns. If we want both, we
should consider separating them into different ontologies (with the
"dynamic" one importing/referencing the other). 

Note: I'm putting "static" and "dynamic" in quotes because there may be
better names for these two concerns.

Note that most elements in the current ontology are for case (i), while
others (actually very few), like the hasFunctionalityStatus and
hasDeployedMedium properties for systems, and the Deployment class are for
more "dynamic" data management purposes, case (ii).


Please provide any relevant information/links below

Section "Intrinsic vs. management properties" in
http://marinemetadata.org/community/teams/ontdevices/agendas/am20090721

Original issue reported on code.google.com by [email protected] on 19 May 2010 at 11:27

[GoogleCodeExporter]

Another "dynamic" concept currently in the ontology is 
AppliedOperationalProcedure,
which allows to capture the date when an OperationalProcedure was applied to a 
System.

http://marinemetadata.org/pipermail/ontdev/2009/000290.html

Original comment by [email protected] on 20 May 2010 at 8:26

[GoogleCodeExporter]

Per telecon of 10 Aug 2010, my own opinion is that "intrinsic" vs "management" 
is a better description.  I think temporal aspects alone do not characterise 
what is intrinsic to System and its subclasses about the value of a property.  
To try to understand what these four attributes of a property might be, I 
created the spreadsheet http://bit.ly/DevOntIssue10
from devont version 20100810T004853. To the Properties list I added four 
columns intrinsic (BobM); mgmt(BobM); dynamic(BobM); static(BobM). In these 
boolean fields I added my opinion as to the applicability of each of the four 
to the property in its row.  I invite you to add four columns and play the same 
game.  

I haven't got very far, but noticed that I can't make the decisions without 
considering some of the other attributes of the given property. Most relevant 
are the the Domain and Range.  This is important, because another point raised 
in today's meeting was that I tentatively believe that the reason Domains are 
there at all is primarily as a documentation feature, not as something about 
the formal semantics. See minutes of August 10 20010 meeting.

--Bob Morris

Original comment by morris.bob on 10 Aug 2010 at 6:00

[GoogleCodeExporter]

Per 2010-10-05 telecon, several elements removed from the DevOnt, see below.

Also, changed the summary of this issue to:
   Separation of "intrinsic" vs, "management" concerns



Changes reflected in http://mmisw.org/ont/mmi/20101005T221039/device
(diagram: http://marinemetadata.org/files/mmi/device-20101005T221039.png)

Removed management aspects related with deployments:
- property Device hasDeployment Deployment
- property Deployment deployedDevice Device
- other associated properties having Deployment as domain (hasLocation, 
start/endDate)
- class Deployment
- property Device hasDeployedMedium Medium

Removed management aspects related with applied operational procedures:
- property Device hasAppliedOperationalProcedure AppliedOperationalProcedure
- property AppliedOperationalProcedure appliedOperationalProcedureSystem Device
- property AppliedOperationalProcedure hasOperationalProcedure 
OperationalProcedure
- other associated properties having AppliedOperationalProcedure as domain
- class AppliedOperationalProcedure
- removed property CalibrationValue hasCount int  (unclear what it was about)

Other management aspects removed (for consistency with the above):
- property OperationalProcedure hasOperationalProcedureCompletion {uncomplete, 
successful, unsuccessful}
- property OperationalProcedure hasOperationalProcedureUniqueId string.  I 
think this was intended as an ID for the particular application of the 
operation procedure.
- property OperationalProcedure producesOperationalProcedureLog string  (label: 
producesLog)
- property Device hasFunctionalityStatus {broken, calibrated, operational, 
verified}
- removed property CalibrationValue hasTypedValue TypedValue (label: hasValue). 
Removed under the assumption that this property was to capture the resulting 
value when some calibration procedure is applied. Now, if the intend is to 
capture values that are expected (including ranges), then we can 
re-incorporate, say with the name hasExpectedValue.

Original comment by [email protected] on 5 Oct 2010 at 10:57

• Changed state: Started

[GoogleCodeExporter]

changed the summary of this issue to:
   Separation of "intrinsic" vs. "management" concerns

Original comment by [email protected] on 5 Oct 2010 at 11:38

• Changed title: Separation of "intrinsic" vs. "management" concerns