GEC11InstMeasWorkingSession: 072511_MDOD_Discussion.txt

File 072511_MDOD_Discussion.txt, 8.2 KB (added by hmussman@bbn.com, 8 years ago)
Line 
1072511
2
3MDOD Discussion
4
51)  MDOD data model
6  a)  one data model, with a few, key, mandatory elements
7  b)  adapted to different situations with various optional elements
8 
92)  MDOD format (syntax)
10  a)  use XML record (file) for transfers between services;  store within services as desired, e.g., as a file, in a DB, etc.
11  b)  specify with XML schema (for correctness) plus "business rules" (for consistency)
12 
133)  MDOD schemas
14  a)  v0.2.x XML-like example (HEM)
15  b)  v0.3x RelaxNG-Compact version (EK);  includes RNC and converted XSD files, both schema and types
16 
174)  MDOD schema structure
18  a)  identifier(s); descriptor(s);  holder(s)
19  b)  can have multiple identifers, but only one primary identifier
20  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
21  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.
22  e)  a holder may include one or more transaction records, in order of occurance;  these provide provenance of the object
23 
245)  MDOD identifer
25  a)  can have multiple identifers
26  b)  but only one primary identifier
27  c)  primary identifer must be of type urn, following GENI urn format:  domain:subdomain+object_type+object_name
28  d)  issue:  need to understand all of the fields in GENI urn format
29  e)  source of primary identifier must be holderid_1, the originator of the object
30  f)  holderid_1 points to holderid_1 element, where holderid_1 is fully defined
31  g)  primary identifier must be unique;  this means that object_name must be unique for this domain:subdomain
32  h)  issue:  how can holderid_1 be sure to pick unique object_name?
33  i)  can have secondary identifer that is temporarily assigned, e.g., perfSONAR key;  such as GENI rspec cleint_id
34
356) MDOD descriptors
36  a)   includes all information to locate and interpret the object
37  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.
38  c)  only one top-level (level 1) descriptor
39  d)  a top-level (or any other) descriptor may include one or more "descriptors_nextleveldown", which recursively follow the same schema
40  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
41  f)  includes "GENI identifiers", to indicate slice that is being measured;  project_id [mandator?  optional?];  slice_id [mandatory]
42  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?
43  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?
44  i) includes "category" element, equivalent to perfSONAR EventType, with optional paramaters, equivalent to perfSONAR parameters;  how specified?;  restricted list?;  mandatory or optional?
45  j)  includes mandatory locator, that points to the object;  includes "point-of-view"
46  k)  can have "global" point of view, where locator (e.g., url) can always be resolved 
47  l)  can have "per_association" point of view, where locator is bound to the object, e.g, included within the object
48  m)  can have a "within_holder" point of view, where locator only works within indicated holder, i.e., a path in that domain:subdomain
49  n)  optional "access_method_ can be used to provide further instructions for locator;  what could be included here?
50  o)  object_format specifies format of object from a restricted list, e.g. perfSONAR API;  e.g., IML NSQL DB
51  p)  associated interpretation_method provides details
52  q)  object_format and interpretation_method must completely specify object, including fields, units, etc.;  this must be detailed for every type of object
53  r)  encryption element indicates if data is encrypted;  if so, encryption_method provides more information;  how is done?
54 
557)  MDOD holders
56  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
57  b)  is there a better term than "holder"? 
58  c)  numbered in order of "holding"
59  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.
60  e)  specified by id, i.e., holderid_1, so can be referenced by other elements
61  f)  it is expected that there will be different types of holders, including:  GENI slice;  GENI user;  non-GENI user
62  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?
63  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?
64  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?
65  j)  when a non-GENI user is holder, how are they specified?;  by email address?;  or ?
66  k)  may include elements for first holder to indicate the collection_policy that was followed, and any anonymization method used;  more details?
67  l)  may include elements for first holder to specify sharing_policy and disposal_policy;  how would this be done?
68  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?
69 
708)  MDOD annotation
71  a)  annotation elements may be included in other elements, as noted.
72  b)  intended to provide an "electronic lab notebook".
73 
74 
75 
769)  Mapping from MDOD elements to InstrumentationTools elements
77
78
79
8010)  Mapping from MDOD elements to OML elements
81
82
83
8411)  Mapping from MDOD elements to perfSONAR elements
85
86  Within MA srvc:
87
88  1)  Identifier (primary)              metadata id  (source = MA srvc)
89
90  2)  identifier (secondary)            key   (source = client)
91
92  3)  object_type                       meas-data-srvc_API
93
94  4)  target                            Subject
95
96  5)  category                          Event Type
97
98  6)  parameters                        Parameter
99
100  7)  locator                   url for MA srvc (to get data)
101
102  7b)   view=global
103
104  7c)  holder                   holderid_1 = MA srvc
105
106  7d)  value                    portal url
107
108  8)  Object_format             perfSONAR API
109
110  9)  interpretation method     ??
111
112  10)  holderid_1               MA srvc,
113
114  10b)  domain
115
116  10c)  subdomain
117
118  10d)  contact         url for MA srvc (to get authorization)
119
120  10e)  transaction             assigned to Client
121
122  Within Client srvc:
123
124  As above
125
126  11)  holderid_2               Client
127
12812)  Mapping from MDOD elements to perfSONAR elements
129
130
13113)  Mapping from MDOD elements to GENI rspec elements
132
133Within AggMgr srvc:
134
135  1)  Identifier (primary)              component_uuid, component_name  (source = AggMgr srvc)
136
137  2)  identifier (secondary)            client_id   (source = client/experimenter)
138
139  3)  object_type                       element type = node|link|extension
140
141  4)  target                            topology location
142
143  5)  category                          e.g., PC_type
144
145  6)  parameters                        e., slicer_type, disk_image, interface... 
146 
147  7)  holderid_1                AggMgr
148
149  7b)  domain
150
151  7c)  subdomain
152
153  7d)  contact          component_mgr
154
155  7e)  transaction 1            assigned to holderid_2
156 
157  7f)  trnasaction 2         returned from  holderid_2
158 
159  8)  holderid_2                                Client/Experimenter, specified by slice_id
160
161  Within Client/Experimenter srvc:
162
163  As above
164
165  8b)  transaction 1            assigned by holderid_1
166 
167  8c)  trnasaction 2         returned to holderid_1