| 200 | | * v0.1 design reviewed at GEC13 [http://groups.geni.net/geni/attachment/wiki/GEC13Agenda/InstrumentationAndMeasurement/T5%29%20%20MDOD%20Status%20-%20CNRI.pptx slides] (Giridhar Manepalli) Conclusion: too complex [[BR]] |
| | 200 | * v0.2 design reviewed at GEC13 |
| | 201 | |
| | 202 | Summary of current status (Giridhar Manepalli): [[BR]] |
| | 203 | [http://groups.geni.net/geni/attachment/wiki/GEC13Agenda/InstrumentationAndMeasurement/T5%29%20%20MDOD%20Status%20-%20CNRI.pptx slides] [[BR]] |
| | 204 | |
| | 205 | Conclusions: [[BR]] |
| | 206 | |
| | 207 | Good things: [[BR]] |
| | 208 | Excellent start [[BR]] |
| | 209 | Collaborative Specification [[BR]] |
| | 210 | Great Coverage [[BR]] |
| | 211 | Nicely broken down into elements [[BR]] |
| | 212 | Mandatory vs. optional elements identified [[BR]] |
| | 213 | Genuine Use Cases: Gathering, transferring, and sharing [[BR]] |
| | 214 | |
| | 215 | Jensen's proposal (NetKarma): [[BR]] |
| | 216 | Current: Identifiers, Descriptors, Holders [[BR]] |
| | 217 | Proposed: Identification, Lineage/Provenance, Constraints/Security, MDO Description [[BR]] |
| | 218 | |
| | 219 | Zurawski's comments: [[BR]] |
| | 220 | Too many secondary identifiers [[BR]] |
| | 221 | Descriptors should be contextualized [[BR]] |
| | 222 | Variations based on the type of object [[BR]] |
| | 223 | GENI specific descriptions should be clearly marked and separated [[BR]] |
| | 224 | Slight changes to names & enclosing elements recommended [[BR]] |
| | 225 | |
| | 226 | Comments/suggestions based on metadata practices: [[BR]] |
| | 227 | Too many optional elements [[BR]] |
| | 228 | Too many choices given to users [[BR]] |
| | 229 | Users bound to take the path of least resistance [[BR]] |
| | 230 | Keep the scope restricted to only mandatory elements – at least in the beginning [[BR]] |
| | 231 | Try those out. Implement them. [[BR]] |
| | 232 | One size fits all ---- No! [[BR]] |
| | 233 | Capturing descriptions, formats, policies, transactions, etc. in a monolithic fashion [[BR]] |
| | 234 | Register individual components separately [[BR]] |
| | 235 | E.g., Capture legal formats & interpretations in their own records, and reference them here [[BR]] |
| | 236 | E.g., Same with accepted policies [[BR]] |
| | 237 | Identifiers cannot be semantic [[BR]] |
| | 238 | Domain, sub-domain, and object-type are part of an ID [[BR]] |
| | 239 | World view changes frequently [[BR]] |
| | 240 | Non-semantic Ids are worth every penny [[BR]] |
| | 241 | Search engines & registries mask the opaqueness [[BR]] |
| | 242 | After all, IDs are just entities behind the scenes [[BR]] |
| | 243 | Object Type controlled vocabulary enumerates apples and oranges [[BR]] |
| | 244 | Collection, flow, directory, file, database, gui are not mutually exclusive [[BR]] |
| | 245 | Doesn’t help the recipient make any decision looking at the descriptor [[BR]] |
| | 246 | Bundle type & format into format interpretation method [[BR]] |
| | 247 | Covers too many corner cases, e.g., flow-rate [[BR]] |
| | 248 | Expects too many details, e.g., locator (type, access method, etc.) [[BR]] |
| | 249 | |
