- ogsa-d-wg - lists.ogf.org

The big picture, version 3
by Dave Berry 02 Feb '06

02 Feb '06

Here is version 3, in light of the comments from yesterday's call. Dave. -----Original Message----- From: owner-ogsa-d-wg(a)ggf.org [mailto:owner-ogsa-d-wg@ggf.org] On Behalf Of Dave Berry Sent: 30 January 2006 11:35 To: ogsa-d-wg(a)ggf.org Subject: [ogsa-d-wg] The big picture, version 2 All, Here is a revised version of the "big picture" architecture diagrams. I've taken account of the feedback I received by e-mail and at last week's meeting. Please take a look and send comments. Dave.

2 1

Fw: Updated Data Architecture Document
by Allen Luniewski 02 Feb '06

02 Feb '06

The message below, with its attachment, has not made it to the list in ~17 hours so I am concerned that the attachment (even though only ~1.2 MB) has caused a problem. So, I have placed the document on GridForege at: /projects/ogsa-d-wg/document/Strawman-Architecture_V.6.0.3/en/1 Please see the note below for details about this version of the document and a request for feedback. Thanks. Allen ----- Forwarded by Allen Luniewski/Almaden/IBM on 02/02/2006 10:18 AM ----- Allen Luniewski/Almaden/IBM 02/01/2006 04:58 PM To ogsa-d-wg(a)ggf.org cc Subject Updated Data Architecture Document I have completed my pass over the data architecture document. The updated document is attached to this note. This note outlines what I have done and asks for your comment and feedback. Once we have had an initial round of feedback and dealt with those, I will then place this version on Grid Forge as our current "truthful" document. Here is a summary of what was done: - Terminology consistency. I have tried to ensure that terminology such as data resource, data service, policy and agreement are used consistently in the document. - Places where work needs to be done by other WGs have been explicitly identified. There are a lot of these! - I have tried to simply edit. I have tried to avoid making semantic changes to the document. If I have inadvertently changed the semantics of the document, this is almost certainly unintended. - The security chapter was moved to just after the "Architectural context" chapter. It made no sense for such a generally applicable set of material to be at the end of the document. - The Data Access section is the last version that Mario published. I have not edited it pending completion of Mario's work. - All "yellow background" text has been eliminated. I either concluded that the text in the document already covered the issue or I took a stab at addressing it. - Some sections that are not in scope for this version of the document have been deleted. - All previous changes were accepted. All changes in the document represent changes made in this editing pass. - Minor typographical, spelling and grammatical errors have been corrected. - There are a number of unbound references that need to be resolved. I will do this sin the next pass - your help in finding proper targets will be appreciated. A goal of this pass was to get us closer to a document that could be put out for public comment = a "clean" document if you will. That is why much "extraneous" text was eliminated. Please send your comments and feedback to the entire list or just to me, as seems most appropriate. Next Wednesday's teleconference will be used to review this version of the document and all comments received up to then. Allen [attachment "OGSA_Data_Architecture_Straw_Man [V.0.6.0.3].doc" deleted by Allen Luniewski/Almaden/IBM]

1 0

Telcon minutes
by Dave Berry 02 Feb '06

02 Feb '06

Minutes for this week's telcon are now on GridForge (http://tinyurl.com/c79vx) Dave.

1 0

Updated Data Architecture Document
by Allen Luniewski 02 Feb '06

02 Feb '06

I have completed my pass over the data architecture document. The updated document is attached to this note. This note outlines what I have done and asks for your comment and feedback. Once we have had an initial round of feedback and dealt with those, I will then place this version on Grid Forge as our current "truthful" document. Here is a summary of what was done: - Terminology consistency. I have tried to ensure that terminology such as data resource, data service, policy and agreement are used consistently in the document. - Places where work needs to be done by other WGs have been explicitly identified. There are a lot of these! - I have tried to simply edit. I have tried to avoid making semantic changes to the document. If I have inadvertently changed the semantics of the document, this is almost certainly unintended. - The security chapter was moved to just after the "Architectural context" chapter. It made no sense for such a generally applicable set of material to be at the end of the document. - The Data Access section is the last version that Mario published. I have not edited it pending completion of Mario's work. - All "yellow background" text has been eliminated. I either concluded that the text in the document already covered the issue or I took a stab at addressing it. - Some sections that are not in scope for this version of the document have been deleted. - All previous changes were accepted. All changes in the document represent changes made in this editing pass. - Minor typographical, spelling and grammatical errors have been corrected. - There are a number of unbound references that need to be resolved. I will do this sin the next pass - your help in finding proper targets will be appreciated. A goal of this pass was to get us closer to a document that could be put out for public comment = a "clean" document if you will. That is why much "extraneous" text was eliminated. Please send your comments and feedback to the entire list or just to me, as seems most appropriate. Next Wednesday's teleconference will be used to review this version of the document and all comments received up to then. Allen

1 0

Minutes of F2F meeting
by Dave Berry 31 Jan '06

31 Jan '06

Two sets of minutes from the Sunnyvale F2F are on GridForge. One is my report of the discussion we had about files on the Monday morning (http://tinyurl.com/c3gp3) The other is Neil's report of the OGSA WG session on ByteIO and the Data Architecture on the Thursday morning (http://tinyurl.com/c85w2) Dave.

1 0

The big picture, version 2
by Dave Berry 30 Jan '06

30 Jan '06

All, Here is a revised version of the "big picture" architecture diagrams. I've taken account of the feedback I received by e-mail and at last week's meeting. Please take a look and send comments. Dave.

2 1

Who should maintain URIs for data formats, query languages, transfer protocols, etc.?
by Dave Berry 30 Jan '06

30 Jan '06

All, One set of gaps in the current data architecture concerns lists of URIs for naming data formats, query languages, transfer protocols, access interfaces, and similar entities. We need URIs to name these things, but it isn't clear who should (a) choose those URIs and (b) maintain these lists. Here are some possibilities: I'd appreciate your thoughts and comments. One possibility is that GGF should have a group specifically to do this (possibly even the OGSA-D group ourselves). As people request new URIs, this WG could issue them, and record them in a central list. Or, people could submit URIs that they have defined themselves, and the WG could maintain a list of them. Another possibility is that each WG that defines an interface could define any relevant sets of URIs. This is along the lines of GFD.58 (which actually defines namespaces), and is the approach that ByteIO are using. The advantage of this is that the work is decentralised. The disadvantage is that the URIs may be used by more than one specification (in fact we generally hope that this will be the case), so the burden of maintaining the list may fall on people who are no longer involved. Also, WGs are disbanded when their work is complete. One important consideration is that many vendors will want to define their own URIs. E.g. a vendor may want a variant of SQL to be defined with a URI under a namespace of that vendor. Conversely, we can't require every supplier to create their own URI, because many will not bother to do so. It's possible that we don't need a central list of all such URIs. If various groups define URIs themselves, then as long as users know which URI applies to their case, they can use it successfully. Volunteer sites could record lists of commonly-used URIs. The disadvantage of this is that it may lead to synonyms, which might cause confusion. Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

Telcon agenda for February 1st
by Dave Berry 30 Jan '06

30 Jan '06

Dear All, The next teleconference of the OGSA Data Architecture working group will be held on Wednesday, February 1st, 2006 at the usual time of 8:00am Pacific / 11:00am Eastern / 4:00pm UK / 5:00pm Europe. In this telcon we will review progress, including the items discussed on the mailing list this week. Please contribute your ideas and suggestions. If you would like to propose other topics, please contact me. Here is the updated teleconference information: UK dialin: 0845 245 0224 US dialin: 1 866 838 0046 Intl dialin: +44 1452 542309 Passcode: 275359 Agenda for the February 1st teleconference: 1) Early discussion (5 minutes) Note taker assignment Roll call Minutes Approval (http://tinyurl.com/9g9eb) Agenda bashing 2) Action report (5 minutes) - Stephen to add a paragraph to the architecture document about reasons for naming. - Stephen will update the scenarios document with comments from the F2F. - Dave to start a mail conversation about managing URIs. - Dave to revise the "big picture" diagrams. - Dave to send draft definition of "data federation" to list for feedback. - Allen to work on an integration pass, including a scoping section. - Ann to check the Access section for suitability for file replication. - Mario to arrange update of the ByteIO subsection. - Section authors to add security notes to their sections. - Everyone to talk with your contacts to get more participation in this WG. - Allen/Dave to contact David Martin & Hiro Kishimoto to get reviewers & expert participation. 3) Progress & planning update (5 minutes) Report of F2F meeting Update on document writing, links with other WGs, plans for telcons up to GGF16. 4) Review of F2F presentation (40 minutes) Overview of architecture document. Identify gaps that need to be addressed. Clarify scope. etc. 5) Wrap up (5 minutes) Next meetings: Feb 8th: Document reviews Feb 13th-16th: GGF16 in Athens Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

[ogsa-wg] Survey for GGF16, GGF17, and interim F2F in April
by Hiro Kishimoto 30 Jan '06

30 Jan '06

Hi all, and sorry for the cross-posting. As you already know, OGSA-WG is planning to have F2F meetings back-to-back with GGF16 (Athens) and GGF17 (Tokyo). We are also planning to have interim F2F meeting in April (venue TBD). Please let us know your plan for attendance and preference by answering the following on-line survey. http://www.zoomerang.com/survey.zgi?p=WEB224YECBCXZY OGSA-WG will discuss meeting plans at the upcoming weekly call on Monday, Jan. 30th, 4-6pm CST. And hard deadline for this survey is Sunday, Feb. 5th. Thanks, -- Hiro Kishimoto

1 1

RE: Data federation definition
by Dave Berry 27 Jan '06

27 Jan '06

Folks, We need a definition of how we are using the term "data federation", for the OGSA glossary. Fortunately we don';t have to find a definition that covers all the ways the term is used in the world, just how we use it in our document. Following a short discussion at the OGSA F2F, Jem (who is keeper of the glossary) suggested the following; The integration of multiple data resources so that they can be accessed as if they were a single resource. Allen suggested that as we are accessing data via services, this would be better phrased as follows (see the attached message for Allen's explanation in his own words): The integration of multiple services or data resources so that they can be accessed as if they were a single service. We discussed this on yesterday's call and the consensus was that I should post to the list and ask for your comments. We briefly discussed whether we should separately define "data federation" and "data integration". One view was that "integration" didn't necessarily involve distributed resources while "federation" didn't necessarily involve integrating the resources into a single view. The contrasting view was that integration almost always involves distributed data in practice, and especially so in a Grid context, while federation typically requires some way of accessing the distributed data as a whole. So I'm leaning towards treated the terms as synonyms within our documents. What do you think? Dave. _____ From: Treadwell, Jem [mailto:jem.treadwell@hp.com] Sent: 19 January 2006 23:17 To: Dave Berry Subject: Data federation definition Dave: This is (very slightly) modified from your document - though you don't have the glossary entry filled in :0) The integration of multiple data resources to so that they can be accessed as if they were a single resource. - Jem _____ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

4 3