These are notes I made from the comments made during yesterday's
presentation. I stress that we encourage people to review the documents
and give us feedback. I also think it is urgent that we produce a
common subset of scenarios combining EMS & Data services.
1. All references to "profiles" in the presentation should have been to
"further normative specifications" - which may include profiles where
appropriate. The primary point is that we need to encourage key specs
and to incorporate them into the OGSA Roadmap.
2. The slides did not clarify that the "Architecture" takes a toolbox
approach, rather than a predefined relationship between the services.
3. The diagram showing the relationships between interfaces, services &
resources should allow multiple resources per service. It should use
the same style as the later diagrams (i.e. showing services & resources
separately rather than as concentric layers).
3a. The Architecture and Services documents should use the same diagram
styles - probably the one used in the OGSA 1.5 document.
4. The "Basic Structure" diagram should add a "Storage Access" interface
(or perhaps just a sink/source interface for data transfer). Also,
"Other Data Services" should be renamed to "Data Management" - there is
no intention to distinguish these services per se from the other "Data
Management" services in the diagram. Note: This diagram also appears in
the OGSA 1.5 document.
5. The "Composite Entities" diagram should include a "federation
management interface" and a "cache management interface". I got the
impression that the diagram was not successful in showing that the
federation and cache services exposed the same interfaces as their
"supplier" services; it might be better to repeat these interfaces on
the federation and cache services rather than using the dotted line.
Note: This diagram also appears in the OGSA 1.5 document.
6. An alternative implementation of the Data Pipelining scenario could
use StreamableByteIO between the Visualisation service and the stored
animations. It might be worth giving this example to show the different
ways that the services can be used to implement a solution.
7. The "Bringing data online" scenario should clarify why data transfer
is used instead of data access. Perhaps the phrase "read files" should
be changed to "transfer files".
8. In the "Data Staging" scenario, the "Parameter Space Exploration
Service" should probably be replaced by a script engine or workflow
enactment engine.
9. There was a discussion about the meaning of the term "policy". It
was suggested that the sample "policies" listed on the slides were
better described as sample parameters for policies. The Data
Architecture document attempts to use the term policy consistently and
we'd be happy to take guidance on improving this presentation.
10. The slide about "Common Properties" was floating an idea. The
comments from the group were that if these properties were to be
generalised, then the ParentDataResource should be an EPR instead of a
URI and should allow multiple parents. Also, the "Sensitivity"
properties were basically an expression of the consistency model, which
in the general case could be more complex (as indeed we have noted
elsewhere in the Data Architecture document).
11. Some of the functionality of the WS-DAI (optional) CoreResourceList
interface will be provided by the WS-Naming facility - specifically the
the functionality of the Resolve operation. RNS is not the appropriate
reference here because it deals in strings instead of URIs. The other
operation provided by the CoreResourceList interface,
GetDataResourceList, does not belong with WS-Naming (and perhaps would
better fit with the possibly-generic properties on the previous slide).
12. DFDL was mentioned in the discussion about "OGSA Data gaps", as a
possible mechanism for describing file "schemas". In fact the slide was
simply referring to POSIX-style "stat" information but we do see DFDL as
a potential description mechanism. The current section on "Data
Description" in the Data Architecture document probably needs some
fleshing out to consider possible languages in more detail.
13. There was some discussion of what is meant by a "data service".
The terminology used in the Data Architecture document is that "Data
Services" are the subset of the OGSA services that deal with data and
hence include services for data transfer, data access, data replication,
storage management, etc. There is an alternative body of opinion that
data access services should be terminologically privileged, i.e. that
the term "data service" should mean a data access service.
14. Regarding the Information Model, Jay mentioned that a key piece of
information is whether a data resource is logically "near" another
resource. This is of use to schedulers, workflow enactments and
applications trying to choose which data resource to use, among other
examples. It isn't clear how to incorporate this information into an
information model (although this should not stop us developing other
aspects of that model).
I encourage everyone to review the Data Architecture and Data Services
documents. These documents will be released under the OGSA brand and we
are at a good stage to take on board any comments.
Best wishes,
Dave Berry
Deputy Director, Research & E-infrastructure Development
National e-Science Centre, 15 South College Street
Edinburgh, EH8 9AA +44 131 651 4039
