Mark McKeown wrote:
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.
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. Donal.