[Plastic-devs] illegal/unrecommended use of IVOA identifiers

[John Taylor]

Hi again Ray,

Ray Plante wrote:
 > Hi John,
 >
 > On Fri, 17 Nov 2006, John Taylor wrote:
 >
 >> First up, apologies for the delay in replying to this. There is A Reason
 >> behind the choice of ivoids as messages.  They're meant to be unique, so
 >> using a URI seems to be reasonable.  Why a registry URI?  Well, we think that
 >> there could be a benefit in registering the messages as separate resources.
 >>
 >
 > I believe you can do all of this with the syntax I recommended, e.g.
 >
 >     ivo://votech.org/plastic#info/getIVORN
 >
 > That is, you would be able to:
 >     o  search the registry to discover the meaning of this message
 >     o  search the registry for applications that support this message
 >     o  have a tool interogate the registry to build a GUI for the message
 >
 > These capabilities would rely on:
 >     o  there being registered a Plastic resource, of type "Standard" where
 >        the messages are defined.
 >     o  there being tools that register their support for the messages
 >        (say as capabilities).
 >
It's certainly an alternative worth considering, though I see two
problems: 1) we're already using the #fragment for something else 2) it
centralises the definition of messages in one place - we want to avoid
this.  So far all the messages have been defined "with the votech.org
authId" (bad bad choice), but I'd really like to see
ivo://estar.org/voevent/do/something/funky appear at some point.  Now
we'd be crazy to let Alasdair get his hands on our publishing
registry...so how would he add his message to the master list?

 > The motivation for this alternative is to preserve two principles consider
 > very important:
 >     o  that you can, via a registry, dereference an IVO ID to a
 >        description.
 >
Sure, I admit that it's a rather strange wrinkle if we don't end up
registering them.  But...
ivo://surely
ivo://you/dont
ivo://claim/ownership
of those 6 little letters?  The message strings themselves will by and
large be invisible to users so shouldn't really cause any confusion.

 >     o  that the registry focus on course-grained resources, so that
 >          + we control the rate of growth of the registry, thereby
 >            controling the performance and maintanence costs
 >
We're not talking about very many here in the grand scheme of things.
If you can detect a measurable drop in performance in your registry I'll
buy you a pint and some extra memory out of my next pay packet.  OK, I
know, I know, it's the principle...if every tin pot little project
starts doing this we could be chest deep in VOResources before we know it.
 >          + we not confuse end users with a vast number of resources that
 >            are rarely of interest to them
 >
I reserve comment on that one!
 >          + we not replicate the information content that is better managed
 >            by local providers and accessed through 2ndary services (e.g.
 >            SIA)  (This point is item is less relevent to the plastic
 >            issue.)
 >
Well, as you know, there are differing opinions on whether service
metadata is better accessed from the registry, the service or both.


 > hope this clarifies things,
 >
It does - I hadn't thought of the approach you suggested.

John


 > Ray
 >
 > -------------------------------------------------------------------------
 > Take Surveys. Earn Cash. Influence the Future of IT
 > Join SourceForge.net's Techsay panel and you'll get the chance to share your
 > opinions on IT & business topics through brief surveys - and earn cash
 > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
 > _______________________________________________
 > Plastic-devs mailing list
 > Plastic-devs at lists.sourceforge.net
 > https://lists.sourceforge.net/lists/listinfo/plastic-devs
 >
 >