strawman, applications software metadata

[Thomas McGlynn]

Robert Hanisch wrote:

> Here are some initial ideas about applications software metadata.  This is
> very informal at this point.  Am looking forward to our discussion next week
> at ESAC.
> 
> Cheers,
> Bob
> 
> 
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.


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)

    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.

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.


Going beyond the pure registry, we may also want to consider what it
means to register software.  I really think the way to get this to work
is to make sure it works for non-interactive applications.
So for library and application downloads, one detail that needs to be considered
is how we accommodate different versions of the software for different architectures.
We could modify the service URL in some standard way (with a controlled vocabularly
for supported architectures).  Or we could consider something like what we do
with SIAP and SSAP services and the ServiceURL could return a table has a row for
each of the supported architectures (and columns designating which architecture
each row corresponds to).

Hope this isn't getting too complex too quickly!


	Tom