GEC11InstMeasWorkingSession: 072811Zurawski_instance1.xml

File 072811Zurawski_instance1.xml, 8.6 KB (added by hmussman@bbn.com, 8 years ago)
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2
3<!--
4Based on http://groups.geni.net/geni/attachment/wiki/GEC11InstMeasWorkingSession/072511_ver0.2.1_MDOD_DataModel.txt
5-->
6
7<measurement_data_object_descriptor>
8 
9  <identifiers>
10 
11    <!-- only one primary allowed -->
12    <identifier rank="primary"
13                type="urn | variable | key | token"
14                source="holderid_1"
15                value="text | urn [better...]" />
16    <!-- or the following, with no attributes ...
17    <identifier>
18      <rank>primary</rank>
19      <type>urn | variable | key | token</type>
20      <source>holderid_1</source>
21      <value>text | urn [better...]</value>
22    </identifier>
23    -->
24   
25    <!-- many secondaries ? -->   
26    <identifier rank="secondary"
27                type="urn | variable | key | token"
28                source="holderid_1"
29                value="text | urn [better...]" />
30       
31    <title>text</title>
32    <abstract>text</abstract>
33    <subject>text</subject>
34    <keywords>text</keywords>
35    <annotation>
36      <user_id>text</user_id>
37      <date_time>text</date_time>
38        <!-- ISO Date prefered -->
39      <entry>text</entry>
40    </annotation>   
41
42    <!--
43    JZ 7/27
44   
45    Comments:
46   
47    - The 'identifiers' enclosing element doesn't seem necessary to me.  I
48      suppose if it will always contain all identifiers (primary and secondary),
49      otherwise these could live at the top level and be referenced by ID (all of the
50      other elements would then be put inside of each/some of the ids)
51    - I would rename the 'value' of the priamry identifier object 'id' instead
52    - Will the secondary's ever be seperated from the primary?  If so we need
53      'id' and 'idRef' constructs to act as pointers
54    - use a well specified date type   
55    --> 
56       
57  </identifiers>
58
59
60 
61  <descriptors>
62
63    <!--
64    JZ 7/27
65   
66    Comments:
67   
68     - Right off the bat I am not sure about a single 'descriptor' based on the
69       contents.  There probably should be multiple descriptors, one for each of
70       the data types (e.g. the target/category would change). 
71     - Does the location make sense in here?  Seems like it would be better in
72       the holder, unless we misunderstand what the holder is...
73     - What is the 'level' exactly?
74     - 'object_type' wasn't well liked.  Service Type instead?  describing ways
75        to access (in some cases), not data formats 
76           
77    -->     
78                 
79    <descriptor level="1"
80                object_type="meas_data_collection | meas_data_flow | meas_data_directory | meas_data_file | meas_data_database | meas_data_service_portal | meas_data_service_GUI">
81                                               
82      <!-- or the following, with no attributes ...
83      <level>1</level>
84      <object_type>meas_data_collection | meas_data_flow | meas_data_directory | meas_data_file | meas_data_database | meas_data_service_portal | meas_data_service_GUI</object_type>
85      -->
86     
87      <collection_geographic_location>text</collection_geographic_location>
88      <!-- Would rather see this end up in the location element -->
89 
90      <collection_start_date_time>numerical</collection_start_date_time>
91      <collection_end_date_time>numerical</collection_end_date_time>
92      <!-- would a lifetime make more sense here? -->
93
94      <project_id>text</project_id>
95      <slice_id>text</slice_id>
96      <experiment_id>text</experiment_id>
97      <run_id>text</run_id>
98      <!-- all of these are geni related, I would favor some grouping, e.g.
99     
100      <geni project_id="" slice_id="" experiment_id="" run_id="" />
101      -->
102
103      <target>text</target>
104      <!-- similar to pS subject, would argue this is a lot more complex than just text -->
105     
106      <category>
107        <parameters>
108          <parameter>text</parameter>
109          <parameter>text</parameter>
110        </parameters>
111      </category>
112      <!-- simlar to pS eventType, would rather see it be:
113
114      <categories>
115        <category>text</category>
116      </categories>
117      -->
118     
119
120      <object_size>numerical</object_size>
121      <flow_rate>numerical</flow_rate>
122
123      <object_format>perfSONAR_API|OML_DB|GUI|etc</object_format>
124      <interpretation_method></interpretation_method>
125                                                                                                                               
126      <encryption>yes|no</encryption>   
127      <encryption_method></encryption_method>
128
129      <!-- I would claim the prior 6 are heavily related to the 'object_type', this would beg for us to have different 'dialects' of descriptor.  E.g. if you are a certain type, you have special elements.  -->
130
131      <locator>
132        <view>global|per_association|within_holder</view>
133                <holder>holderid_n</holder>
134                <type>path|url|other</type>
135                <value>text</value>
136                <access_method>text</access_method>
137      </locator>
138
139      <!-- I am not really sure this is the right place for this.  I wold envison that this is more related to the holder ... so it would make more sense to do the following:
140     
141        <descriptor>
142          <holder idRef="holder1"
143        </descriptor>
144
145        <holder>
146          <location>
147            <view />
148            <type />
149           
150            etc...
151           
152          </location>
153        </holder>           
154       -->
155                     
156      <annotation>
157        <user_id>text</user_id>
158        <date_time>text</date_time>
159          <!-- ISO Date prefered -->
160        <entry>text</entry>
161      </annotation> 
162
163      <!--
164      Do we need this here?  I guess it doesn't hurt ... maybe this beggs for a special top annotation object?
165      -->
166
167      <descriptors_nextleveldown>
168        <descriptor level="2">
169        <!-- -->
170        </descriptor>
171                <!-- ... -->
172      </descriptors_nextleveldown>
173 
174      <!--
175      I am struggling with what this is.  I am assuming its to enforce some sort of layering of descripors, but I am not sure that makes sense.  I would imagine that descriptors are all at the same 'level' (e.g. see my earlier comment about needning more than one)
176      -->
177
178    </descriptor>
179   
180  </descriptors>
181 
182  <holders>
183
184    <!--
185    JZ 7/27
186   
187    Comments:
188    --> 
189       
190    <holder id="holderid_1" order="1">                 
191      <!-- or the following, with no attributes ...
192      <id>holderid_1</id>     
193      <order>1</order>         
194      -->
195
196      <domain>geni.net</domain>         
197      <subdomain>holder_1.org</subdomain>               
198
199      <!-- maybe these make sense as a urn? -->
200
201      <slice_id>text</slice_id>
202      <user_id>text</user_id>
203      <!-- all of these are geni related, I would favor some grouping, e.g.
204     
205      <geni user_id="" slice_id="" />
206     
207      project_id, experiment_id and run_id don't seem to be here ...
208      -->
209
210      <contact>
211        <type>email|url|other</type>
212        <value>text</value>
213      </contact> 
214     
215      <!-- This can be bolstered with a more complete 'service level' description from the perfsONAR world, would have some of the 'location' stuff from descriptor (see proposal above) -->
216
217      <collection>yes|inherited</collection>
218      <collection_policy></collection_policy>
219                                                       
220      <anonymization>yes|yes_inherited|not_required</anonymization>
221      <anonymization_method></anonymization_method>     
222     
223      <sharing>allowed|allowed_inherited|not_allowed</sharing>
224      <sharing_policy></sharing_policy>
225                                                       
226      <disposal>specified|specified_inherited|not_specified</disposal>
227      <disposal_policy></disposal_policy>       
228     
229      <!-- all 8 of these are 'policy' related, mayeb we need a special policy element to enclose them all?
230     
231      <policy>
232        ...
233      </policy>
234     
235       -->
236       
237      <transaction>
238        <transaction_id>text</transaction_id>
239        <transaction_type>collected|received|returned|registered|modified|shared|assigned|etc.</transaction_type>
240        <transaction_date_time>text</transaction_date_time>
241        <transaction_info></transaction_info>           
242                                                                       
243        <annotation>
244          <user_id>text</user_id>
245          <date_time>text</date_time>
246            <!-- ISO Date prefered -->
247          <entry>text</entry>
248        </annotation> 
249                                                                       
250      </transaction>
251     
252      <!-- I don't disagree that this is an imporant thing ... I am not sure this is a first class citizen in the MDOD though.  I am thinking of this as 'data' really.  Here is my crazy idea:
253     
254       - A service that tracks the tranactions (e.g. it would be a 'log MA' or something similar
255     
256       - That service registers with an LS just like any other
257       
258       - We can describe the specific service that this MDOD cares aboubt:
259       
260       
261       <transaction>
262         <contact> etc. etc. </contact>
263       </transaction>
264       -->
265     
266
267    </holder>
268 
269  </holders>
270 
271</measurement_data_object_descriptor>
272
273
274