Hi Donal,
Regarding Chris's desire to be able to pass the LSF jobid back to the client somehow - it could be included in the EPR's Metdata, possibly RDF could be used to mark up the Metadata to indicate that it is a LSF jobid. In this way the Address IRI can be kept opaque.
That would seem to me to be needless disambiguation. Surely it is just up to the service that mints the abstract name to understand it; there is no inherent need for it to explain what that means to anyone else.
I am not sure I understand your comment - you don't seem to be disagreeing with me... Frank wants to use the EPR's wsa:Address IRI as an AbstractName, Chris wants to send a LSF jobid to the client and the W3C recommends that IRIs should be opaque. One way to include the LSF jobid in the EPR is to embed it into the wsa:Address IRI, this might help make it unique and the client could extract it from the IRI - however the W3C recommends that IRIs should be opaque. To resolve this issue I suggested putting the LSF jobid into the wsa:Metadata of the EPR, the tooling generally only looks at this if it knows to look for something. It might be possible to use RDF to mark up the wsa:Metadata. The wsa:Metadata can become stale, so retrieving a new version of the EPR may return different wsa:Metadata (eg a different LSF jobid). In this way it is possible to keep the EPR wsa:Address IRI opaque to the client and pass the LSF jobid back to the client in the EPR (if you really want to pass the LSF jobid around in the EPR). So I agree with your statement "Surely it is just up to the service that mints the abstract name to understand it; there is no inherent need for it to explain what that means to anyone else." Are the names that RNS provides opaque?
There is an interesting question as to whether sending the LSF jobid back to the client somehow breaks encapsulation - eg if I submit a job, the job is allocated a local jobid, the job is checkpointed, stopped then restarted on a different system with a different local jobid.
I think that just indicates that the abstract job (the one that you're talking about) is not the same as the two concrete jobs that implement it, and as such would have different names to both of them. On the other hand, it would be entirely reasonable to query the abstract job to find out what its current (or, indeed, historic) concrete jobs are.
I am not familiar with the levels of abstraction that BES wants to support, I guess it defines "abstract" and "concrete" jobs? cheers Mark
Donal.