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)