strawman, applications software metadata

[Paul Harrison]

Thomas McGlynn wrote:
>>
>>
> Hi Bob,
> 
> Some thoughts on this since I won't be in Spain next week.
> 
> This seems like a good start for users interactively scanning the 
> registry to
> look for software of interest.  We'll need more details for software to 
> be able
> to use it though.

I think that making the registry "machine readable"  - from our 
experience, I feel that the "bare registry" is almost never directly 
useful to end users - they either do not know how to start making a 
query, or are overwhelmed but the results - some machine intelligence 
needs to be accomodated to interpret the results - even in the case of 
direct registry browser.
> 
> 
> E.g., I think we need a field with the semantics something like:
> 
>    SoftwareType has the possible values "Library", "Application", "Service"
> (and perhaps others).
> 
>    Library implies that this software element cannot run on its own, it 
> somehow
> needs to be combined with other software elements to form something 
> which can
> execute.  A library needn't be a link library, it could be something like
> a stylesheet that's used to provide an output skin.
> (DownloadURL is a link to the library download)

I feel that Library might be sufficiently different from Application and 
Service to need separate treatment - however what would be good is to 
find the base class for these different descriptions and then to have 
derived resource descriptions that could have different details, rather 
than trying to squeeze them all into one type.

> 
>    An Application is a piece of software which can run as an executable 
> on a machine.
> However no host is supplied.  An application can be dependent on one or 
> more libraries.
> This is a piece of software that a user might download and run on their own
> machine.  (DownloadURL is a link to the executable download)
> 
>    A Service is a hosted Application.  It can be directly invoked by a 
> user.
> (ServiceURL is a link to the service directly, and may be modified 
> according
> to a service interface.  We already have many Services in the registry. 
> A DownloadURL
> may be provided, and if so links to a version of the application that 
> the user can
> run on their own machine.)
> 
> Both applications and services should have some mechanism for defining 
> the interface
> to the tool, e.g., something that plays the role of WSDL.   I'm not sure we
> want to use WSDL itself in this role, but for the moment I just think we 
> need
> a placeholder in the metadata for whatever it is that will describe the 
> interface.
> So you might have a:
>     InterfaceURL
> field for applications and services and I suppose we could do this for 
> libraries too.  I'd
> suggest making the InterfaceURL mandatory for Service, strongly 
> recommended for applications
> and optional for libraries.

CEA already has a (non-WSDL) description of the application interface, 
that could equally well be used in the case where the "Application" is a 
web service (as is now the case) or where the application is something 
that is downloaded to the user's desktop, where the interface would 
describe the initial parameters that could be passed to the application. 
Under the VOTech project, we are looking at the further possibility of 
defining a standard interface by which two such desktop applications 
could communicate with each other once running to provide the user with 
an enhanced interactive experience - pretty much based on the way that 
Aladin interacts with VOPlot at the moment for instance. There is 
potentially extra metadata invloved in this description.

> 
> This ties back naturally to our existing registry entries for various 
> services.
> to encompass all of the existing ConeSearch, SIAP and SkyNode services.  
> We only need to update
> those with some description of their interface and I'd hope we could do
> that by pointing to some standard document for each service type.
> 
> There are as many as four URLs defined for a piece of software:
> 
>     ReferenceURL:  links to definitive descriptions/documentation of the 
> software (always required)
>     DownloadURL:   links to a download capability for the software 
> (required for Library/Application optional
>                    for Services)
>     InterfaceURL:  links to a description in some TBD standardized 
> format for how the software
>                    is invoked (required for Service, recommended for 
> Application, optional for library)
>                    Many services (e.g., all cone search services) may 
> point to the same InterfaceURL
>                    (Perhaps an interface URL can be assumed for certain 
> service types?)
>     ServiceURL:    links to a URL that invokes a service (mandatory for 
> Service, not supplied for
>                    Library or Application
> 
> 
> I also wonder if we need to have a little more detail in the Function 
> area.  Perhaps
> this should be expanded a little...  E.g., consider the WCS fixer tools 
> we're building.
> I think it's perfectly reasonable to anticipate that I'd want to be able 
> to find
> one of these dynamically in software, but we need more information, so I 
> think we'll
> want to have controlled vocabulary at a fairly explicit level of 
> detail.  This may
> couple with the interface description.
> 
> So WCS Fixer is
>      DataDomain:
>        EM regime:   Infrared,Optical
>        Input:       Image
>        Output:      Image
>        Interactive: No
>      Function:
>        Type:        Analysis/Filter
>        Keywords:    WCSFixer
> 
> 
> The DataDomain doesn't talk about detailed formats (e.g., FITS vs 
> VOTables) but only
> about the kind of data supported in terms of broad data models
> (Image, Spectra, TimeSeries, ObjectList, Photons, ObservationList, 
> Table).   This
> part isn't really a serious proposal, but I think we need to understand
> how software is going to be able to find appropriate applications.

This is the really tricky one to do well, but we should try to get the 
people who are trying to do ontologies for astronomical objects to also 
think about the descriptions of the various analysis methods for 
astronomical data, so that the astronomer can ask for all the tools that 
  can perform reduction technique X  using algorithm Y on datatype Z - I 
do not believe that this has had the attention that it deserves yet.



-- 
Paul Harrison
ESO Garching
www.eso.org