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