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 | | |