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