Profile for EPR's Address as "abstract name" ?
I'm starting to sound like a broken record, but I'd like to get a clear statement and direction from the ws-naming authors whether they believe that such a profile is or should be part of their charter. The issues, requirements and possible solutions have been discussed on the list by Tom and myself, but no reactions or follow-up has occurred. Please... Thanks, Frank. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
I found the call today very helpful. One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES. I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique. Are there others? Regards -- Ian.
For a mapping of BES to LSF, I would put something like a job id in the abstract name, so that it could be used outside the web services world (say with a CLI). Sure, it could be put in the payload of messages, or retrieved via some explicit call, but it seems reasonable to use the abstract name for this. -- Chris On 9/11/05 17:28, "Ian Foster" <foster@mcs.anl.gov> wrote:
I found the call today very helpful.
One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES.
I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique.
Are there others?
Regards -- Ian.
Hi Chris, Could you expand a little on the scenario and use case? Will the job id be the abstract name itself or embedded in it? What kind of resolution is needed and when? (jobId=>EPR?) Could the jobId be embedded inside of the EPR's address? Thanks, Frank. Christopher Smith wrote:
For a mapping of BES to LSF, I would put something like a job id in the abstract name, so that it could be used outside the web services world (say with a CLI). Sure, it could be put in the payload of messages, or retrieved via some explicit call, but it seems reasonable to use the abstract name for this.
-- Chris
On 9/11/05 17:28, "Ian Foster" <foster@mcs.anl.gov> wrote:
I found the call today very helpful.
One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES.
I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique.
Are there others?
Regards -- Ian.
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
I haven't thought too much about it, but it would probably be something like the abstract name being the jobid (maybe plus the submit time for some time uniqueness if desired). I could then possibly use this to resolve to an EPR if needed. The jobid is used for both WS and non-WS interfaces, so that it's easier for clients (i.e. people) to remember them and pass them around. So, say someone gets an email from LSF about the job, which contains the LSF jobid, they can then use their portal (which uses the WS interface) to get more information. As for embedding in the EPR's address, I thought that it was not supposed to be "interpreted" by the people that they are handed to. :-) Of course, as I mentioned, this could also easily be done by embedding this information in the payload of some SOAP messages. -- Chris On 9/11/05 18:24, "Frank Siebenlist" <franks@mcs.anl.gov> wrote:
Hi Chris,
Could you expand a little on the scenario and use case?
Will the job id be the abstract name itself or embedded in it?
What kind of resolution is needed and when? (jobId=>EPR?)
Could the jobId be embedded inside of the EPR's address?
Thanks, Frank.
Christopher Smith wrote:
For a mapping of BES to LSF, I would put something like a job id in the abstract name, so that it could be used outside the web services world (say with a CLI). Sure, it could be put in the payload of messages, or retrieved via some explicit call, but it seems reasonable to use the abstract name for this.
-- Chris
On 9/11/05 17:28, "Ian Foster" <foster@mcs.anl.gov> wrote:
I found the call today very helpful.
One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES.
I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique.
Are there others?
Regards -- Ian.
Embedding the jobId in the EPR's Address' URI was not meant to be interpreted by the clients, but was meant to give it the same uniqueness properties ans the jobId itself. If that is the case, then the job's Address becomes an alternative name for the job - forget the fact that it is also used as a network end point: it's just another jobId by itself. The mapping of the jobId to the job's Address value is resolvable at the manager that created the Address (it has to be). Now the only thing that bothers me is your insistence that some warm-body has to be able to "remember" them... isn't it enough to be able to easily copy and paste them ? (note that IDs that are forever globally unique and such are *always* "impossible" to remember... so I'm not even sure if that is a realistic requirement... unless you have yet another not so abstract name in mind with less uniqueness properties). It's a little difficult to go into details as the use case is somewhat sketchy... but the main idea that I wanted to introduce is to treat the Address value also as an identifier for the resource. Regards, Frank. Christopher Smith wrote:
I haven't thought too much about it, but it would probably be something like the abstract name being the jobid (maybe plus the submit time for some time uniqueness if desired). I could then possibly use this to resolve to an EPR if needed. The jobid is used for both WS and non-WS interfaces, so that it's easier for clients (i.e. people) to remember them and pass them around.
So, say someone gets an email from LSF about the job, which contains the LSF jobid, they can then use their portal (which uses the WS interface) to get more information.
As for embedding in the EPR's address, I thought that it was not supposed to be "interpreted" by the people that they are handed to. :-)
Of course, as I mentioned, this could also easily be done by embedding this information in the payload of some SOAP messages.
-- Chris
On 9/11/05 18:24, "Frank Siebenlist" <franks@mcs.anl.gov> wrote:
Hi Chris,
Could you expand a little on the scenario and use case?
Will the job id be the abstract name itself or embedded in it?
What kind of resolution is needed and when? (jobId=>EPR?)
Could the jobId be embedded inside of the EPR's address?
Thanks, Frank.
Christopher Smith wrote:
For a mapping of BES to LSF, I would put something like a job id in the abstract name, so that it could be used outside the web services world (say with a CLI). Sure, it could be put in the payload of messages, or retrieved via some explicit call, but it seems reasonable to use the abstract name for this.
-- Chris
On 9/11/05 17:28, "Ian Foster" <foster@mcs.anl.gov> wrote:
I found the call today very helpful.
One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES.
I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique.
Are there others?
Regards -- Ian.
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Just some of my thoughts/ideas on the topic.... I view abstract names simply as resource GUIDs which could be persistent, shared, and referenced over time (meaning the abstract name will never change). Within BES, I would like to use them in particular for items which are long lived, such as references to an Application Archive in ACS within a job description. I would expect that the abstract name would survive over a long period of time as machines fail, IPs are re-issued, domain name changes, etc. One could construct a job using the simpler abstract name, save that job (JSDL, etc), and at some time later request the job to execute and the ACS archive could be found, assuming it still exits (in which case the audit logs might be examined for references to that abstract name). I was also curious about the use of them with regard to policy documents (security and agreement) because even if the service host changes, those abstract names are static and therefore would not make the policy documents obsolete. Ian Foster wrote:
I found the call today very helpful.
One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES.
I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique.
Are there others?
Regards -- Ian.
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)
Hi Michael, As I argued in my reply to Chris, you should be able to use the actual EPR's Address for this purpose if you consider it as a simple identifier instead of an endpoint reference, and if you ensure that it has the right uniqueness properties. -Frank. Michael Behrens wrote:
Just some of my thoughts/ideas on the topic.... I view abstract names simply as resource GUIDs which could be persistent, shared, and referenced over time (meaning the abstract name will never change).
Within BES, I would like to use them in particular for items which are long lived, such as references to an Application Archive in ACS within a job description. I would expect that the abstract name would survive over a long period of time as machines fail, IPs are re-issued, domain name changes, etc. One could construct a job using the simpler abstract name, save that job (JSDL, etc), and at some time later request the job to execute and the ACS archive could be found, assuming it still exits (in which case the audit logs might be examined for references to that abstract name).
I was also curious about the use of them with regard to policy documents (security and agreement) because even if the service host changes, those abstract names are static and therefore would not make the policy documents obsolete.
Ian Foster wrote:
I found the call today very helpful.
One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES.
I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique.
Are there others?
Regards -- Ian.
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Hi Frank, A number of points/questions... By advocating using the Address element of the EPR as the AbstractName are you saying that ReferenceParameters should NOT be used to map messages to backend resources? (Two WSRF EPRs can have the same Address element but use ReferenceParameters to map to different WSRF resources) The Address is an IRI, ie it can be a URN. It has never been clear to me how EPR's that use URNs in the Address element should be used, though people seem quite keen on them. Either the client can somehow map the URN to a physical network location or it can get another service to resolve the URN to a physical network location - are you adovcating using URNs as the Address element? 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. 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. cheers Mark
Hi Michael,
As I argued in my reply to Chris, you should be able to use the actual EPR's Address for this purpose if you consider it as a simple identifier instead of an endpoint reference, and if you ensure that it has the right uniqueness properties.
-Frank.
Michael Behrens wrote:
Just some of my thoughts/ideas on the topic.... I view abstract names simply as resource GUIDs which could be persistent, shared, and referenced over time (meaning the abstract name will never change).
Within BES, I would like to use them in particular for items which are long lived, such as references to an Application Archive in ACS within a job description. I would expect that the abstract name would survive over a long period of time as machines fail, IPs are re-issued, domain name changes, etc. One could construct a job using the simpler abstract name, save that job (JSDL, etc), and at some time later request the job to execute and the ACS archive could be found, assuming it still exits (in which case the audit logs might be examined for references to that abstract name).
I was also curious about the use of them with regard to policy documents (security and agreement) because even if the service host changes, those abstract names are static and therefore would not make the policy documents obsolete.
Ian Foster wrote:
I found the call today very helpful.
One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES.
I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique.
Are there others?
Regards -- Ian.
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
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.
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.
Mark McKeown wrote:
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.
Well, I also believe that it's better to keep the IRIs opaque and was suggesting to use the complete IRI itself as an alternative jobId. Whether that could work depends on the use cases we have to consider... -Frank. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
On 10/11/05 10:35, "Frank Siebenlist" <franks@mcs.anl.gov> wrote:
Mark McKeown wrote:
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.
Well, I also believe that it's better to keep the IRIs opaque and was suggesting to use the complete IRI itself as an alternative jobId.
Whether that could work depends on the use cases we have to consider...
See this is exactly what I want to avoid. Our customers are used to seeing a regular jobID (now if this is generated by a higher level scheduler that understands checkpointing and migration and the fact that lower level jobids might change, that's fine). The use this jobID within command line tools and web portals to access information about their job. The web services interfaces are now an additional interface to these others. Why should I bring WS baggage along (in the form of EPRs and IRIs as identifiers) when I have one that our users understand already. I don't want to have to retool my CLI and other existing interfaces to now take some other structured identifier. The abstract name seems to me like a nice way of providing this identifier in the context of the WS interface. Sure, many of the alternative proposals would do the trick as well, but I had always been under the assumption that clients weren't supposed to interpret the EPR elements. -- Chris
Christopher Smith wrote:
On 10/11/05 10:35, "Frank Siebenlist" <franks@mcs.anl.gov> wrote:
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.
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.
Well, I also believe that it's better to keep the IRIs opaque and was suggesting to use the complete IRI itself as an alternative jobId.
Whether that could work depends on the use cases we have to consider...
See this is exactly what I want to avoid.
Our customers are used to seeing a regular jobID (now if this is generated by a higher level scheduler that understands checkpointing and migration and the fact that lower level jobids might change, that's fine). The use this jobID within command line tools and web portals to access information about their job. The web services interfaces are now an additional interface to these others. Why should I bring WS baggage along (in the form of EPRs and IRIs as identifiers) when I have one that our users understand already. I don't want to have to retool my CLI and other existing interfaces to now take some other structured identifier.
The abstract name seems to me like a nice way of providing this identifier in the context of the WS interface. Sure, many of the alternative proposals would do the trick as well, but I had always been under the assumption that clients weren't supposed to interpret the EPR elements.
I can relate to your CLI requirement, but as I've noted before, using an AbstractName will not solve your warm-body interface problem as all globally forever unique IDs are not user friendly. If I understand it well, then what you want is to work within the context of a CLI interaction such that you can use relatively small numbers for jobIDs that only have to be unique within that context. In other words, your job#12 today will be different from you job#12 tomorrow, which requires confinement to context. You could probably still use AbstractNames and use some naming convention to essentially concatenate a contextId and a small numbered jobId... and define your own URI-schema for that. Of course if only you were "allowed" to parse those EPR-Address URIs, you could do the same thing ;-) Regards, Frank. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Hi Chris,
Well, I also believe that it's better to keep the IRIs opaque and was suggesting to use the complete IRI itself as an alternative jobId.
Whether that could work depends on the use cases we have to consider...
See this is exactly what I want to avoid.
Our customers are used to seeing a regular jobID (now if this is generated by a higher level scheduler that understands checkpointing and migration and the fact that lower level jobids might change, that's fine). The use this jobID within command line tools and web portals to access information about their job. The web services interfaces are now an additional interface to these others. Why should I bring WS baggage along (in the form of EPRs and IRIs as identifiers) when I have one that our users understand already. I don't want to have to retool my CLI and other existing interfaces to now take some other structured identifier.
The abstract name seems to me like a nice way of providing this identifier in the context of the WS interface. Sure, many of the alternative proposals would do the trick as well, but I had always been under the assumption that clients weren't supposed to interpret the EPR elements.
A client can examine an EPR, for example an EPR can contain Meta data about itself. However a client should not examine any ReferenceParameter an EPR may contain, ReferenceParameters are ment to be opaque. http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/#eprinfomodel cheers Mark
Hi Mark, Mark McKeown wrote:
Hi Frank, A number of points/questions...
By advocating using the Address element of the EPR as the AbstractName are you saying that ReferenceParameters should NOT be used to map messages to backend resources? (Two WSRF EPRs can have the same Address element but use ReferenceParameters to map to different WSRF resources)
I'm afraid that my own preference shown through here as life would be simple with just IRIs ;-) ...but no, I realize that the ReferenceParameters will be used to carry the dispatch info. In the past I've given a recipe how one could construct an identifier/name from the address+refParameters by essentially concatenating the Address value with some base64 blob of the canonicalized refParameters (or if space is a consideration, append the digest value of the refParmeters...) This transformation essentially would give you the Address value as the name when no refParameters are present. For this to work, the transformation should be standardized such that all parties can generate the same IRI-name, and it still requires a profile on the uniqueness properties for the combined Address+RefParameters for this to be a useful name (URN).
The Address is an IRI, ie it can be a URN. It has never been clear to me how EPR's that use URNs in the Address element should be used, though people seem quite keen on them. Either the client can somehow map the URN to a physical network location or it can get another service to resolve the URN to a physical network location - are you adovcating using URNs as the Address element?
I'm advocating that the Address element's IRI can both be used as an URN, i.e. just a name/identifier that is not expected to be resolved to anything, and an endpoint reference address. (Note that the latter may today provide you with a true communication path to your resource but tomorrow it may be stale... but profiling shound ensure that it should never, ever refer to a different resource)
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. 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.
Right, and one alternative would be to use the Address itself as the jobId. If the job would migrate to another system with a different local jobId, it would also have a different Address IRI, and we need a more stable job-name to deal with that, which could be an AbstractName, or could be through the renewableReference's IRI that can also be viewed as a jobId. This points out that if the RenewableReference's IRI can be used as a name (URN), then this essentially can be used for the exact same purpose as the AbstractName. Regards, Frank.
Hi Michael,
As I argued in my reply to Chris, you should be able to use the actual EPR's Address for this purpose if you consider it as a simple identifier instead of an endpoint reference, and if you ensure that it has the right uniqueness properties.
-Frank.
Michael Behrens wrote:
Just some of my thoughts/ideas on the topic.... I view abstract names simply as resource GUIDs which could be persistent, shared, and referenced over time (meaning the abstract name will never change).
Within BES, I would like to use them in particular for items which are long lived, such as references to an Application Archive in ACS within a job description. I would expect that the abstract name would survive over a long period of time as machines fail, IPs are re-issued, domain name changes, etc. One could construct a job using the simpler abstract name, save that job (JSDL, etc), and at some time later request the job to execute and the ACS archive could be found, assuming it still exits (in which case the audit logs might be examined for references to that abstract name).
I was also curious about the use of them with regard to policy documents (security and agreement) because even if the service host changes, those abstract names are static and therefore would not make the policy documents obsolete.
Ian Foster wrote:
I found the call today very helpful.
One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES.
I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique.
Are there others?
Regards -- Ian.
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Frank Siebenlist wrote:
...
By advocating using the Address element of the EPR as the AbstractName are you saying that ReferenceParameters should NOT be used to map messages to backend resources? (Two WSRF EPRs can have the same Address element but use ReferenceParameters to map to different WSRF resources)
I'm afraid that my own preference shown through here as life would be simple with just IRIs ;-)
...but no, I realize that the ReferenceParameters will be used to carry the dispatch info.
In the past I've given a recipe how one could construct an identifier/name from the address+refParameters by essentially concatenating the Address value with some base64 blob of the canonicalized refParameters (or if space is a consideration, append the digest value of the refParmeters...)
This transformation essentially would give you the Address value as the name when no refParameters are present.
For this to work, the transformation should be standardized such that all parties can generate the same IRI-name, and it still requires a profile on the uniqueness properties for the combined Address+RefParameters for this to be a useful name (URN).
I realize that it could cause confusion, but in this discussion, whenever I use the Address as a name, it is essentially a simplified version of what I stated above. In other words, for the discussion we can ignore the referenceParameters and pretend they don't exist ;-) -Frank. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
participants (6)
-
Christopher Smith -
Donal K. Fellows -
Frank Siebenlist -
Ian Foster -
Mark McKeown -
Michael Behrens