Date: 16 January 2008 18:41:06 GMT
Subject: [MYGRID] a few additional thoughts after the metadata/EMO meeting
Hi,
long email, prob. best added to a wiki page? (which one?)
the long discussion earlier today on metadata management in T2/myExperiment has clarified many modelling and architectural issues
and generated new ideas.
whereby an EMO is basically a structured container for references (links, URIs) to external resources.
I would like to add a couple of points in this context:
- hashing, digest functions are proposed to check whether the current content obtained by resolving the link is identical to the
original content at the time the EMO was created. This amounts to storing the digest alongside the link in the EMO.
Two thoughts:
- we can also use digests to digitally sign content, for instance to sign workflows in myExp -- which in turn gives
non-repudiability and other authentication-related properties (which we may or may not be interested in)
- digests give byte-level identity verification. In some cases (?) users / apps may be interested in weaker forms of similarity,
i.e., if all that has changed in a workflow since it became part of an EMO are a few comments, then the workflow will fail the
digest test, but may still be "the same" from the point of view of the application. In general, for some familiar data types,
including workflow definitions, we may be able to offer users the choice of a variety of quasi-identity test functions, as well as
"diff" functions to compare versions.
This is based on the intuition that different apps may have different tolerance to version mismatches in the resources. Can this
be useful?
- some of the referenced content may be a *managed* resource, or even be under the control of the EMO issuer, for instance the myExp
site. This is not too far-fetched: workflows stored in myExp *are* managed resources.
Two thoughts on this:
- since EMO consumers are sensitive to version changes in the underlying resources, for managed resources we can imagine a
notification mechanism, whereby EMO holders (users, apps) are notified of changes in the resources contained therein. In practice,
when users receive an EMO that points to a managed resource, they also receive the option, when available, to subscribe to changes
in the resource.
In fact, when users receive an EMO they should be able to drop it into an EMO manager which, among other things (resolving
references, mainly), takes care of this notification preferences and behaviour for you. This makes EMOs "active".
- it is sometimes possible to annotate resources that are referenced from an EMO with properties having to do with (i) stability:
is the resource expected to change, is it read-only archive data, is it a persistent and controlled snapshot of an evolving
resource, etc.; (ii) lifetime and availability: is the resource transient, and if so, does it become invalid after a period of time;
etc.
Adding these properties as metadata associated to a resource reference in an EMO could help optimise the EMO resolver algorithm...
--Paolo
--
----------- ~oo~ --------------
School of Computer Science, University of Manchester, UK