Changes between Version 20 and Version 21 of GEC14Agenda/IMDesignTopics


Ignore:
Timestamp:
06/26/12 13:25:45 (7 years ago)
Author:
hmussman@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEC14Agenda/IMDesignTopics

    v20 v21  
    173173 Need MDOD creation and editing service. (who?) [[BR]]
    174174 Need Measurement Data Object identifiers (names);  sometimes need a persistent, public reference;  consider DataCite approach, which uses handle  [[BR]]
    175 
    176 
    177 Summary of v0.1 design at GEC13  (Giridhar Manepalli): [[BR]]
    178  [http://groups.geni.net/geni/attachment/wiki/GEC13Agenda/InstrumentationAndMeasurement/T5%29%20%20MDOD%20Status%20-%20CNRI.pptx  slides]  [[BR]]
    179 
    180  Conclusions: [[BR]]
    181 
    182  Good things: [[BR]]
    183   Excellent start [[BR]]
    184   Collaborative Specification    [[BR]]
    185   Great Coverage [[BR]]
    186   Nicely broken down into elements [[BR]]
    187   Mandatory vs. optional elements identified [[BR]]
    188   Genuine Use Cases:  Gathering, transferring, and sharing [[BR]]
    189 
    190  Jensen's proposal (NetKarma): [[BR]]
    191   Current:  Identifiers, Descriptors, Holders [[BR]]
    192   Proposed:  Identification, Lineage/Provenance, Constraints/Security, MDO Description [[BR]]
    193 
    194  Zurawski's comments: [[BR]]
    195   Too many secondary identifiers [[BR]]
    196   Descriptors should be contextualized [[BR]]
    197   Variations based on the type of object [[BR]]
    198   GENI specific descriptions should be clearly marked and separated [[BR]]
    199   Slight changes to names & enclosing elements recommended [[BR]]
    200 
    201  Comments/suggestions based on metadata practices: [[BR]]
    202   Too many optional elements [[BR]]
    203    Too many choices given to users [[BR]]
    204    Users bound to take the path of least resistance [[BR]]
    205    Keep the scope restricted to only mandatory elements – at least in the beginning [[BR]]
    206    Try those out. Implement them. [[BR]]
    207   One size fits all ---- No! [[BR]]
    208    Capturing descriptions, formats, policies, transactions, etc. in a monolithic fashion [[BR]]
    209    Register individual components separately [[BR]]
    210    E.g., Capture legal formats & interpretations in their own records, and reference them here   [[BR]]
    211    E.g., Same with accepted policies [[BR]]
    212   Identifiers cannot be semantic [[BR]]
    213     Domain, sub-domain, and object-type are part of an ID [[BR]]
    214     World view changes frequently [[BR]]
    215     Non-semantic Ids are worth every penny [[BR]]
    216     Search engines & registries mask the opaqueness [[BR]]
    217     After all, IDs are just entities behind the scenes [[BR]]
    218   Object Type controlled vocabulary enumerates apples and oranges [[BR]]
    219    Collection, flow, directory, file, database, gui are not mutually exclusive [[BR]]
    220    Doesn’t help the recipient make any decision looking at the descriptor [[BR]]
    221    Bundle type & format into format interpretation method [[BR]]
    222    Covers too many corner cases, e.g., flow-rate [[BR]]
    223    Expects too many details, e.g., locator (type, access method, etc.) [[BR]]
    224 
    225 
    226175
    227176Summary  [[BR]]