Thread: Re: [Plastic-devs] illegal/unrecommended use of IVOA identifiers
Brought to you by:
johndavidtaylor,
thomasboch
Menu
▾
▴
plastic-devs
|
From: John T. <jd...@ro...> - 2006-11-17 14:23:43
|
Hi Ray, 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. Messages are unique and there aren't that many of them, so why not register them? That way the URI can be dereferenced to provide a (hopefully) unambiguous definition of what the message means, and who is responsible for its definition. It also opens up other possibilities: the user wants to find an application that can accept a VOTable, a search of the registry reveals the ivo://..../loadVOTable message VOResource, a follow up search then locates the applications that understand the message (assuming we've got as far as registering desktop applications). All this would be hidden away behind some clever helper app of course. Another possibility is you could have some Plastic message sender tool that could interrogate the registry to construct the GUI for any message. Now if we decide not to the register the messages, it doesn't impact on the registry at all...the messages are just rather odd opaque strings....so where's the harm? I do plan to register Plastic as a standard as you suggest - and will probably be bugging you on how to do this. BTW - we can't use URI fragments as you propose, since they have another meaning in Plastic. John PS - the choice of votech.org as an authority Id was a mistake (well, let's be fair - it was my mistake)...I shouldn't have polluted the votech.org authId. Ray Plante wrote: > Hi John et al. > > I don't know if this has been pointed out to you or not; however, the > Plastic Specification is using IVOA identifiers in a non-standard way > to identify its messages. > > The IVOA Identifiers specification > (http://www.ivoa.net/Documents/latest/IDs.html) states that the use of > the ivo indicates that the identifier has been registered with an IVOA > registry (section 3.2.2). > > To be compliant, each of the Plastic message identifiers would have to > be registered as a separate resource. While in principle this is > possible, this is highly discouraged. Instead, I would recommend the > approach that is to be used by the VOSpace standard in which names are > identified using a # suffix; e.g., > > ivo://votech.org/plastic#info/getIVORN > > For use of an identifier of this form to be compliant, only the > ivo://votech.org/plastic resource need be registered. We have a new > schema we are putting forward for this purpose called VOStandard > (http://www.ivoa.net/internal/IVOA/RegUpgradeSummer2006/VOStandard-v0.1.xsd). > > It defines two new Resource sub-classes, Standard and StandardService, > that registers the existance of a standard; the former is probably > most appropriate for Plastic. These types do not currently provide > metadata for defining what I might call properties (e.g. > info/getIVORN); however, we should probably add that. Note that the > standard being described need not be an IVOA standard. > > Please let me know if you have any comment or suggestions on this front. > The Registry WG is the WG that handles the Identifier standard. > > cheers, > Ray > > > -- ------------------------------------------------------------------------ AstroGrid/VOTech & WFAU, Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ *Gratuitous advertising:* Plastic - http://plastic.sourceforge.net | AstroRuntime - http://www2.astrogrid.org/desktop AstroGrid - http://www.astrogrid.org | WFAU - http://www.roe.ac.uk/ifa/wfau/ |
|
From: John T. <jd...@ro...> - 2006-11-17 15:07:13
|
Sorry to post this twice, but I wanted to correct the mistaken plastic devs address in the cc line before more people replied. > > ------------------------------------------------------------------------ > > Subject: > Re: illegal/unrecommended use of IVOA identifiers > From: > John Taylor <jd...@ro...> > Date: > Fri, 17 Nov 2006 15:03:53 +0000 > To: > Roy Williams <ro...@ca...> > > To: > Roy Williams <ro...@ca...> > CC: > Ray Plante <rp...@po...>, > pla...@so..., reg...@iv... > > > Hi Roy, > > Roy Williams wrote: > >> John >> >> Following your logic, this means that VOEvents can also be registered >> individually, rather than registering the server that handles them, >> as Ray suggests. I understand that LSST will be putting out thousands >> of event notices every night. Do you think the VO registry system >> will be able to handle the load? > As I say, there's not very many messages - we're not proposing that > whenever an app sends a message it gets registered. We're registering > the message "class" rather than "instance". I don't really know > enough about VOEvent to comment. >> >> Another problem is inflexibility. Suppose a group wishes to >> experiment with their own dialect of messages, and they want to >> change rapidly, adding and deleting. In the official (Ray) scheme, >> they would have a standalone message registry that may or may not be >> registered with the VO registry. In your scheme, each message is >> added and deleted from the entire global VO registry. > I think it's very flexible. While you're experimenting, don't > register the message. We're not registering them at the moment and > getting along just fine...it's just they wouldn't show up in any tools > that looked in the registry for them, which is probably what you'd > want anyway. Indeed, you could even choose a non-ivoid URI if you > wished. >> >> Of course it is much more convenient to have "everything in the >> registry", it is a one-stop shop instead of a two-stage process. But >> perhaps not always the best solution....... > Indeed. It might turn out that we don't register them after all, but > if so, no harm done. > > John >> >> Roy >> >> >> >> John Taylor wrote >>> a search of the registry reveals the ivo://..../loadVOTable message >>> >>> Ray Plante wrote: >>>> Instead, I would recommend the approach that is to be used by the >>>> VOSpace standard in which names are identified using a # suffix; e.g., >>>> >>>> ivo://votech.org/plastic#info/getIVORN >>> >> > > -- ------------------------------------------------------------------------ AstroGrid/VOTech & WFAU, Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ *Gratuitous advertising:* Plastic - http://plastic.sourceforge.net | AstroRuntime - http://www2.astrogrid.org/desktop AstroGrid - http://www.astrogrid.org | WFAU - http://www.roe.ac.uk/ifa/wfau/ |
|
From: John T. <jd...@ro...> - 2006-11-17 16:07:51
|
Doug Tody wrote: > Hi All - > > In thinking about where this sort of inter-tool messaging might go in > the future, it might be useful to look into the past, for example the > messages which have been defined for the ds9 image display client (which > uses XPA as the underlying messaging transport). See for example > > http://hea-www.harvard.edu/RD/ds9/ref/xpa.html Thanks for this reference - I'm hoping that it won't be beyond us to fashion some kind of plastic-xpa bridge, even at this early stage. I'm sure there's a lot we can and should learn from the way ds9 messaging works. > > One might conclude that messages of this sort can be viewed as a > language, defined separately for each type of tool, based on the types > of data and operations it deals with. I guess we're always going to have a tension between a language tuned to a particular tool and able to expose its full power, and something more general. At the moment we've concentrated on very general messages, although we've toyed with the idea of exposing the full Aladin scripting interface through Plastic. There's probably room for both, though you get a bit tangled up when you have several messages that essentially do the same thing. > When a language becomes rich > enough one would probably prefer to register the namespace or schema > for the language, not the individual elements of the language itself. > Interesting. I wonder whether it's feasible for us to aim at rich languages rather than very simple operations, given the cross-organisation nature of the endeavour. Perhaps I'm being unambitious. However we do this, my feeling at the moment is to keep the messages fairly short strings, rather than (say) going down the route of making them xml. This keeps plastic simple enough to use from the command line in Python. As for namespacing, one of the benefits of using ivoids was that we get namespacing through the authorityIds. At the moment this is purely for the human's benefit - as far as an app is concerned the messages are opaque strings and no plastic app can infer that ivo://votech.org/.../votable/loadFromUrl is related to ivo://votech.org/../votable/showObjects . John > - Doug > > > On Fri, 17 Nov 2006, Roy Williams wrote: > >> John >> >> Following your logic, this means that VOEvents can also be registered >> individually, rather than registering the server that handles them, >> as Ray suggests. I understand that LSST will be putting out thousands >> of event notices every night. Do you think the VO registry system >> will be able to handle the load? >> >> Another problem is inflexibility. Suppose a group wishes to >> experiment with their own dialect of messages, and they want to >> change rapidly, adding and deleting. In the official (Ray) scheme, >> they would have a standalone message registry that may or may not be >> registered with the VO registry. In your scheme, each message is >> added and deleted from the entire global VO registry. >> >> Of course it is much more convenient to have "everything in the >> registry", it is a one-stop shop instead of a two-stage process. But >> perhaps not always the best solution....... >> >> Roy >> >> >> >> John Taylor wrote >>> a search of the registry reveals the ivo://..../loadVOTable message >>> >>> Ray Plante wrote: >>>> Instead, I would recommend the approach that is to be used by the >>>> VOSpace standard in which names are identified using a # suffix; e.g., >>>> >>>> ivo://votech.org/plastic#info/getIVORN >>> >> > -- ------------------------------------------------------------------------ AstroGrid/VOTech & WFAU, Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ *Gratuitous advertising:* Plastic - http://plastic.sourceforge.net | AstroRuntime - http://www2.astrogrid.org/desktop AstroGrid - http://www.astrogrid.org | WFAU - http://www.roe.ac.uk/ifa/wfau/ |
|
From: Doug T. <dt...@nr...> - 2006-11-17 16:27:08
|
On Fri, 17 Nov 2006, John Taylor wrote: > I guess we're always going to have a tension between a language tuned to a > particular tool and able to expose its full power, and something more > general. Probably the key distinction is an interface which simply allows one to "drag and drop" a structured data object onto a tool, and an API used to interactively control or drive a particular tool. Both have their place. PLASTIC seems to be mainly of the "drag and drop" variety. >> When a language becomes rich >> enough one would probably prefer to register the namespace or schema >> for the language, not the individual elements of the language itself. >> > Interesting. I wonder whether it's feasible for us to aim at rich languages > rather than very simple operations, given the cross-organisation nature of > the endeavour. Perhaps I'm being unambitious. Another way to think of it is, if a component exposes an API, we generally want to register a WSDL or some such specification for the API, rather than the individual elements of the API. Perhaps PLASTIC is not a general messaging system at all, capable of exposing stateful APIs or passing general events, but rather a type of object-oriented drag-and-drop mechanism? Is it mostly used to "push" data objects at tools? - Doug |
|
From: Ray P. <rp...@po...> - 2006-11-17 17:04:13
|
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).
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.
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 not confuse end users with a vast number of resources that
are rarely of interest to them
+ 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.)
hope this clarifies things,
Ray
|
|
From: John T. <jon...@gm...> - 2006-11-17 17:26:55
|
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 > > |
|
From: Ray P. <rp...@po...> - 2006-11-17 17:42:06
|
Hi,
On Fri, 17 Nov 2006, John Taylor wrote:
> It's certainly an alternative worth considering, though I see two problems:
> 1) we're already using the #fragment for something else
You can do what ever you like after the # following the IVOA id, including
having another pound.
If it helps, ? has the exact same effect from the IVOA ID perspective--it
marks the end of the identifier that is resolvable via the registry. You
could then have messages that look like
ivo://votech.org/plastic?info/getIVORN#...
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?
So by avoiding centralization, I take you mean that you want to allow
anyone to define a new message. My recommendation is that that through
one Standard resource record, one can define a set of properties (that are
presumably related). You define your core Plastic message; Alasdair, in a
sepearate Standard record, defines his extended set. Applications can
either describe support for whole sets or individual properties.
I think it can work.
cheers,
Ray
|
|
From: Mark T. <m.b...@br...> - 2006-11-17 17:50:30
|
On Fri, 17 Nov 2006, Ray Plante wrote: > On Fri, 17 Nov 2006, John Taylor wrote: >> It's certainly an alternative worth considering, though I see two problems: >> 1) we're already using the #fragment for something else > > You can do what ever you like after the # following the IVOA id, including > having another pound. By my reading of RFC2396 a string of this form would not be a legal URI. -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: John T. <jon...@gm...> - 2006-11-17 18:00:39
|
Hi Ray - This sounds promising (apart from Mark having spotted the gotcha in the URI spec). It also could tie in quite neatly with Doug's idea about namespacing the different "languages". John Ray Plante wrote: > Hi, > > On Fri, 17 Nov 2006, John Taylor wrote: > >> It's certainly an alternative worth considering, though I see two problems: >> 1) we're already using the #fragment for something else >> > > You can do what ever you like after the # following the IVOA id, including > having another pound. > > If it helps, ? has the exact same effect from the IVOA ID perspective--it > marks the end of the identifier that is resolvable via the registry. You > could then have messages that look like > > ivo://votech.org/plastic?info/getIVORN#... > > 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? >> > > So by avoiding centralization, I take you mean that you want to allow > anyone to define a new message. My recommendation is that that through > one Standard resource record, one can define a set of properties (that are > presumably related). You define your core Plastic message; Alasdair, in a > sepearate Standard record, defines his extended set. Applications can > either describe support for whole sets or individual properties. > > I think it can work. > > cheers, > 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 > > |
