hi mario such pictures indeed help to get the discussion focussed and to understand what is actually the current line of thought. i have a few questions relating to it. i will later also try to put up another concept map for a big picture we were working with in EGEE. [the cmap tool is nice!] - DataSet is data externalised from the data resource: do you mean that what determines a dataset is not residing in the data resource itself but somewhere external? i seem to be missing something.. - composite data service: what do you mean by the unbounded link? (sorry if i missed some discussions here) - i don't understand how data virtualization can provide data management and data access. i understand how it provides data creation (i think) but also then shouldn't it be described the other way round? i.e. data virtualization can trigger data creation? again i seem to be missing something.. so i still have problems with understanding what different people mean by 'virtualization', do you we have a final definition if this yet? i may have an outdated version of the doc.. - looking at your picture, it reads that data capabilities are access,federation,location management and transfer. the problem here is that this is easily misunderstood since 'data capabilities' refers to the grid architecture capabilities, not to capabilities of actual data being stored. so having this in the same image may be confusing. it may help to talk about architectural capabilities and models in a separate image. - i agree with your annotations in the cmap! i think the data description is metadata to be stored either with the data or in a data catalog; and dataset is just like that too, its metadata of the actual data, not data itself. for transfers you would need to look up the metadata and you're right, it doesn't necessarily materialize except on the actual target. peter On Tue, 2005-05-03 at 13:54 +0100, Mario Antonioletti wrote:
Hi, I think one thing that has been lacking a bit in the OGSA-D WG so far has been the bigger picture trying to tie some of the concepts together. A long time ago I remember seeing the concept maps that were produced for the WS architecture (see: http://www.w3.org/TR/ws-arch/) and I quite liked these. I don't know what tool they used but I found something similar, if not the same. See:
It's a java application and I think, though I've not looked too closely, is free. I have tried to create a concept map for the data architecture and have included an exported image as an attachment to this email as well as the cmap file that contains the source to the diagram in case anyone wants to play with it. It was very easy to generate and change and I believe the cmaps can be shared so they could be developed in a collaborative fashion. I think it helps to ellicit detail from the model, e.g. to what does the data description bind to: the virtualization or the service? Does the idea of having a data set defined in the data transfer make sense? i.e. I think of a data set as a disconnected piece of data that has been materialised outside the data resource and this would only make sense if it were staged. Do we benefit at all from making the distinction between a simple and aggregated data service? etc, etc, etc.
Note that I am not advocating that these should be included in the document, nor that everything should go in one diagram (as is currently). I think that the diagrams can be nested (maybe). Is this a worthwhile thing to do? If the answer is yes can it be done so the diagrams are shared? Thoughts?
I will try to distribute something on data access by the close of day today (UK time) albeit it'll be far from complete.
Mario
+-----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | +-----------------------------------------------------------------------+ --
CERN, 1211 Geneva 23, Switzerland