GEC11InstMeasWorkingSession: 072511_MDOD_Discussion.txt

072511

MDOD Discussion

1)  MDOD data model
  a)  one data model, with a few, key, mandatory elements
  b)  adapted to different situations with various optional elements
  
2)  MDOD format (syntax)
  a)  use XML record (file) for transfers between services;  store within services as desired, e.g., as a file, in a DB, etc.
  b)  specify with XML schema (for correctness) plus "business rules" (for consistency)
  
3)  MDOD schemas
  a)  v0.2.x XML-like example (HEM)
  b)  v0.3x RelaxNG-Compact version (EK);  includes RNC and converted XSD files, both schema and types
  
4)  MDOD schema structure
  a)  identifier(s); descriptor(s);  holder(s)
  b)  can have multiple identifers, but only one primary identifier
  c)  can have multiple descriptors, nested to provide hierarchical structure;  then one MDOD can be used to describe all of the data associated with a slice over a period of time;  however, only one top-level (level 1) descriptor
  d)  one or more holders, that "hold" the object;  numbered in order of "holding";  first holder (holderid_1) originated the object, i.e., gathered the measurement data, and (per I&M archtecture) is felt to "own" the object.
  e)  a holder may include one or more transaction records, in order of occurance;  these provide provenance of the object
  
5)  MDOD identifer
  a)  can have multiple identifers
  b)  but only one primary identifier
  c)  primary identifer must be of type urn, following GENI urn format:  domain:subdomain+object_type+object_name
  d)  issue:  need to understand all of the fields in GENI urn format
  e)  source of primary identifier must be holderid_1, the originator of the object
  f)  holderid_1 points to holderid_1 element, where holderid_1 is fully defined
  g)  primary identifier must be unique;  this means that object_name must be unique for this domain:subdomain
  h)  issue:  how can holderid_1 be sure to pick unique object_name?
  i)  can have secondary identifer that is temporarily assigned, e.g., perfSONAR key;  such as GENI rspec cleint_id

6) MDOD descriptors
  a)   includes all information to locate and interpret the object
  b)  can have multiple descriptors, nested to provide hierarchical structure;  then one MDOD can be used to describe all of the data associated with one slice over a period of time.
  c)  only one top-level (level 1) descriptor
  d)  a top-level (or any other) descriptor may include one or more "descriptors_nextleveldown", which recursively follow the same schema
  e)  includes object_type from a restricted list of measurement data object types;  object_type in top-level descriptor must match object_type in primary identifer
  f)  includes "GENI identifiers", to indicate slice that is being measured;  project_id [mandator?  optional?];  slice_id [mandatory]
  g)  includes "GENI identifiers", to indicate identify multiple sets of data associated with one slice over a period of time: slice_id [mandatory];  experiment_id  [optional];  run_id [optional];  should these be defined within GENI?;  should there be others?
  h)  includes "target" element, equivalent to perfSONAR subject;  for example, this indicates what hosts in the topology of GENI that are being measured;  issue:  how sepcified?;  issue:  manadtory or optional?
  i) includes "category" element, equivalent to perfSONAR EventType, with optional paramaters, equivalent to perfSONAR parameters;  how specified?;  restricted list?;  mandatory or optional?
  j)  includes mandatory locator, that points to the object;  includes "point-of-view"
  k)  can have "global" point of view, where locator (e.g., url) can always be resolved  
  l)  can have "per_association" point of view, where locator is bound to the object, e.g, included within the object
  m)  can have a "within_holder" point of view, where locator only works within indicated holder, i.e., a path in that domain:subdomain
  n)  optional "access_method_ can be used to provide further instructions for locator;  what could be included here?
  o)  object_format specifies format of object from a restricted list, e.g. perfSONAR API;  e.g., IML NSQL DB
  p)  associated interpretation_method provides details
  q)  object_format and interpretation_method must completely specify object, including fields, units, etc.;  this must be detailed for every type of object
  r)  encryption element indicates if data is encrypted;  if so, encryption_method provides more information;  how is done?
  
7)  MDOD holders
  a)  one or more holders, that "hold" the object;  one originates or gathers the object;  others may receive the object;  this includes users that get to share the object, e.g., are granted access to a GUI
  b)  is there a better term than "holder"?  
  c)  numbered in order of "holding"
  d) first holder (holderid_1) originated the object, i.e., gathered the measurement data, and (per I&M archtecture) is felt to "own" the object.
  e)  specified by id, i.e., holderid_1, so can be referenced by other elements
  f)  it is expected that there will be different types of holders, including:  GENI slice;  GENI user;  non-GENI user
  g)  when a GENI slice is a holder, it can be specified by slice_id;  will this include domain:subdomain?;  can slice_id be used to lookup a contact, i.e., email address?
  h)  in time, the resources associated with a slice are released;  can we assime that the slice_id remains in some registry, so that a slice-id in an MDOD that persists can still be interpreted, i.e., use slice_id to lookup domain:subdmain or contact email address?
  i)  when a GENI user is a holder, i.e, it is granted access to a GUI, it can be specified by user_id;  will this include domain:subdomain?;  can user_id be used to lookup a contact, i.e., email address?;  can we expect user_id to remain in a registry, so that lookup can always be done?
  j)  when a non-GENI user is holder, how are they specified?;  by email address?;  or ?
  k)  may include elements for first holder to indicate the collection_policy that was followed, and any anonymization method used;  more details?
  l)  may include elements for first holder to specify sharing_policy and disposal_policy;  how would this be done?
  m)  a holder may include one or more transaction records, in order of occurance;  these provide provenance of the object;  how would this be done?
  
8)  MDOD annotation
  a)  annotation elements may be included in other elements, as noted.
  b)  intended to provide an "electronic lab notebook".
  
  
  
9)  Mapping from MDOD elements to InstrumentationTools elements



10)  Mapping from MDOD elements to OML elements



11)  Mapping from MDOD elements to perfSONAR elements

  Within MA srvc:

  1)  Identifier (primary)              metadata id  (source = MA srvc)

  2)  identifier (secondary)            key   (source = client)

  3)  object_type                       meas-data-srvc_API

  4)  target                            Subject

  5)  category                          Event Type

  6)  parameters                        Parameter

  7)  locator                   url for MA srvc (to get data)

  7b)   view=global

  7c)  holder                   holderid_1 = MA srvc

  7d)  value                    portal url

  8)  Object_format             perfSONAR API

  9)  interpretation method     ??

  10)  holderid_1               MA srvc, 

  10b)  domain

  10c)  subdomain

  10d)  contact         url for MA srvc (to get authorization)

  10e)  transaction             assigned to Client

  Within Client srvc:

  As above

  11)  holderid_2               Client

12)  Mapping from MDOD elements to perfSONAR elements


13)  Mapping from MDOD elements to GENI rspec elements

Within AggMgr srvc:

  1)  Identifier (primary)              component_uuid, component_name  (source = AggMgr srvc)

  2)  identifier (secondary)            client_id   (source = client/experimenter)

  3)  object_type                       element type = node|link|extension

  4)  target                            topology location

  5)  category                          e.g., PC_type

  6)  parameters                        e., slicer_type, disk_image, interface...  
  
  7)  holderid_1                AggMgr

  7b)  domain

  7c)  subdomain

  7d)  contact          component_mgr

  7e)  transaction 1            assigned to holderid_2
  
  7f)  trnasaction 2         returned from  holderid_2
  
  8)  holderid_2                                Client/Experimenter, specified by slice_id

  Within Client/Experimenter srvc:

  As above

  8b)  transaction 1            assigned by holderid_1
  
  8c)  trnasaction 2         returned to holderid_1