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

[John T. <jon...@gm...>]

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
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/plastic-devs
>
>