[tsc] Responses to Public Comments

David Snelling David.Snelling at UK.Fujitsu.com
Tue Apr 17 07:26:12 CDT 2007


Folks,

And a longer one:

Comments from OGSA Data
https://forge.gridforum.org/sf/go/topc4014

Responses in line:

> Comments from the OGSA Data WG
> Page 8, Table: The list of data capabilities here does not reflect  
> the OGSA architecture.  I suggest that it be replaced
>  with:
>
> Data description
> Data access
> Data transfer
> Data storage
> Data replication
> Data federation
> Data caching
> Data security
> Data provisioning
> Session management
> Distributed transactions
>
> This list includes areas that are currently addressed by the OGSA  
> Data Architecture and additional areas that are
> relevant.  Data provisioning has been addressed by the EGA  
> Reference Model.

To update the list to the current OGSA Data thinking is an excellent  
idea, but this change is more substantial than a simple edit, so I  
would prefer to action this change in the next document version.

> "Metadata" is not a capability. It is simply data that describes  
> other data.  There are many issues related to metadata,
>  including formats, schemas, ontologies, consistency and more.  Add  
> particular ones if you wish, but don't just list "
> metadata".

At the level of generality addressed by the document, all the above  
apply. I believe that the reference covers all the sub categories you  
list, so I think we will leave it for now.

> This table should list provenance tracking as a capability.  This  
> could be added to the data section or possibly another

I would push it to the next version.


> Page 10, Authorisation:  Note that the architecture whereby a using  
> service "calls out" to an authorisation service is
> inadequate for some use cases.  For example, the authorisation  
> policy may be associated with the data being processed
> rather than the processing service.

As is an earlier response, this I believe is a more technical  
comment. But in any case it will probably still need to be a call  
out. We won't make any changes here until the next version.

> Page 11, section 4.4: This should be called "Data transfer", or, if  
> you insist, "Data movement".  The body of the text
> correctly avoids the inaccurate assumption that all data is held in  
> files.

This has been noted by several people and will be fixed.

> Page 11, section 4.5: This should just be called "Data  
> Provisioning".  Data Grids include the other capabilities listed
> and they shouuldn't be lumped together. The first paragraph seems  
> too general for inclusion here; everything it says is
> perfectly correct but it should appear earlier in the document.

These are good points and I this we can make these changes without  
disrupting the document.

> I suggest that you add other sections called "Data Access" and  
> "Storage". You might possibly others called "Data
> Replication" and "Data Federation".

These are certainly areas for inclusion, but this document is not  
aiming at the whole space, but rather an attempt hit high priorities.  
In the next version we may become broader, but this depends of the  
requirement gathering process in OGF. No changes are planed in this  
version.

> Page 13, Table:
>   "File Movement" -> "Data Transfer"

Agreed.

>   "Data Provisioning and Data Grids" -> "Data Access"

Above you suggested just Data Provisioning" I agree.

> ByteIO should be listed under Data Access rather than Data Transfer.

Agreed. We should fix this.

> Page 14, Table:  "OGSA Data" should be listed against Data Access,  
> Data Transfer, Data Replication, Data Storage, Data
> Federation and Data Security - or perhaps just against  
> "Architecture".  It should not be listed against Data
> Provisioning.  The GSM-WG should be listed against Data Storage.   
> Possibly DFDL-WG should be listed against Data
> Description.

Thank you. I agree with these changes, except I think that Data  
Provisioning is certainly within the remit of a Data Architecture WG.

> Typos:
>
> Page 2:  The phrasing of the last sentence on page 2 could be read  
> as saying that our focus is only "trans-national
> collections of supercomputers". This would disappoint most of our  
> industry members.

Will fix.

> Page 3, Collaboration Grids:  "should no" -> "should not"

Will fix.

> Page 8: "Table 2" -> "Table 1"?

Yes.

> Page 8, Table: There are many references in this table to footnotes  
> that do not exist.

There does seem to have been a word problem here. We will try to fix it.

> Page 13: "Table 3" -> "Table 2"?

Yes.

> Page 13, section 5.1:  "Table 4" -> "Table 3", "Table 3" -> 'Table 2"?

Yes.

> Page 14: "Table 4" -> "Table 3"?

Yes

> Page 15: "Geoffery Fox" -> "Geoffrey Fox".

Yes.




-- 

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe Limited
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE
     Reg. No. 4153469

     +44-208-606-4649 (Office)
     +44-7768-807526  (Mobile)





More information about the tsc mailing list