VOApplication: an XML Encoding Schema for Application Resource Metadata
Version 1.0

Introduction

The IVOA Standard, Resource Metadata for the Virtual Observatory [Hanisch et al. 2004] (hereafter referred to as RM) defines metadata terms for describing resources. A specific XML encoding of these resources is described in the IVOA standard VOResource: an XML Encoding Schema for Resource Metadata [Plante et al. 2006] (hereafter refered to as the VR) The "resource" that is described in these documents is a very general concept, and was deliberately designed so that it can be specialized for particular types of resource.

This document specifically describes an extension of the metadata concepts and an XML encoding called VOApplication. The VOApplication schema provides XML encoding that extends the VR so that can be used to describe applications (see section below for discussion of what constitues an application). The intention of creating this model is to allow a framework for finding applications in an IVOA compliant registry and possibly downloading and automatically running them.

The VOApplication Data Model

The concept of an application in the context of this standard can cover almost any computer program or process than can consume and/or emit data. e.g.

• unix command line executables
• java applets
• REST web services
• SOAP web services

Note that although this is a very wide ranging definition, forms of "application" e.g. web services which are specifically covered by other IVOA standards, should normally be described in terms of those standards, rather than as a general VOApplication.

Core VOApplication Metadata

At the IVOA interoperability meeting in Madrid 2005 a list of desired metadata for applications was agreed.

Function

A delimited list, including terms such as reduction, analysis, display, modeling, graphics, format conversion, etc. Multiple terms could be selected.

OperationModes

Interactive, command line, scriptable, from browser, etc.

OpenSource

Yes/No.

SourceURL

Entry point to the source code.

License

Name of license and descriptive text.

Cost

Free; or description of pricing, if not freely available.

SourceLanguage

A delimited list of software development languages. Can be more than one.

Dependencies

A text description of dependencies � compilers, libraries, etc. � that this application needs in order to be compiled or deployed. Include IDs of other applications in the registry upon which this application relies.

NetworkRequired

Essential/Useful/Limited/Unnecessary.

BinarySize

Typical size of the executable.

MemorySize

Typical memory requirements.

Platforms

List of supported platforms (hardware plus operating system).

VOStandards

List of supported VO standards and protocols used or implemented in this application (SIAP, SSAP, ADQL, OSQ, etc.)

InputFormats

List of supported input data formats, e.g., FITS, HDF, VOTable.

OutputFormats

List of supported output data formats, e.g., FITS, HDF, VOTable.

Appliction Version

It is often the case that applications are updated - not clear that the version element that appears in curation is sufficient for the needs (how is the latest version of an application signalled, if access to legacy versions are left in the registry.

Note that this model does not attempt to categorize the function of the application - this is beyond the scope of this standard, and will be covered by either the IVOA Ontology WG efforts, or by the characterization of processes that is being undertaken by the IVOA Theory WG. The only characterization of the application in this model is in terms of the types of inputs or IVOA standards that it supports.

Formal UML model

The main type introduced by this specification is the va:Application which contains all of the generic application metadata. The main subcategorizations of an application are then

Desktop Application

An application that can be executed locally by a user on their desktop machine and is represented by the va:DesktopApplication type.

Software Library

A collection of software that is not directly executable itself, but can be used to build other applications - represented by the va:SoftwareLibrary type.

Remote Application

An application that is executed remotely from the users desktop. There is no specific type defined for this class of application in this VOApplication schema, but this class of application is represented in the diagram above by the CeaApplication type which is defined in a separate standard [CEA]

Details of the VOApplication Schema

Application Type

This is the basic extension to the VOResource type that this schema defines. It is the container for the basic extension metadata that are common to all applications.

cost

an indication as to what the cost of the application is - the string "free" or "none" should be used to indicate that the application does not cost anything. Any value for the cost of any non-free software should be taken to be an approximate cost for one license - it is obviously difficulte to curate this value for non-free software so that the main use of this element will be to distinguish between free and non-free.

license

A free text value that indicates what type of license is in force. This can either be a common name of a license or a URL pointing to the license text.

openSource

A boolean value indicating whether the application is open source.

dataFormat

The concept of input formats and output formats have been collapsed into the single dataFormat element with an additional attribute called direction which can take on the values "read", "write" or "both". The identifiers to be used for the formats are detailed in the section on Enumerations.

voStandard

Any VO standards that the application can support. These should be specified as a ivoa identifier for the standard as detailed in [VSTD]

sourceLanguage

The identifier (as detailed in the section Enumerations) for the principal language that the application is written in.

sourceCodeURL

A URL from where the application source code can be obtained.

DesktopApplication

This is a concrete type that can be used to register real application that can be run on the user's desktop. In addition to the metadata described above, there is the possibility to add metadata for the following properties.

binarySize

The size of the executable in bytes.

memoryRequirement

An estimate in bytes of the mimimum memory that the application requires to function with acceptable interactive performance.

network

An assertion about the network requirements for the proper functioning of the application. This can take on the values;

Essential

The application will not even start without a network connection.

Useful

The application will start, but the primary use for the application requires a network connection.

Limited

The application makes only limited use of network facilities, thus the majority of its functionality is still available without a network connection.

Unnecessary

The application makes no use of the network.

dependsOn

Can be used to indicate other applications/software libraries that the application depends upon. This should only be used to indicate depenedencies that must be installed separately from the application itself e.g. this element should not be used to indicate a dependency on a software library if the library is included in the application download.

executable

This is a complex type that is described further in the section on the ExecutionEnvionment type.

ExecutionEnvironment type

This type is intended to provide enough information for an executable image of the application to be downloaded and possibly automatically run. It should be noted of course that the automatic invocation of an application could possibly be dangerous and it only recommended for environments where a suitable "sandbox" is provided and/or cryptographic verification of the origin of the executable can be made.

platform

The major classification of the platform that the software is compiled for. This should be an ivoa identifier for the platform name as specified in the section on Enumerations.

architecture

The hardware architecture that the software is compiled for, if relevant.

subtype

An optional free format sub-classification name for the platform.

maxVersion

An optional maximum version of the platform that the software image is valid for.

minVersion

An optional minimum version of the platfrom that the software image is valid for.

download

The URL from which the executable image can be downloaded. This can actually take point to different types of entity depending on the platform e.g. for the "unix" platform this would typically point to a compiled executable image (though it might point to an archive or "packaging" file that contains the executable amongst other files). For the "Java Webstart" platform this element will point to a ".jnlp" file that contains all of the information necessary for the Java Webstart technology to download and run the application.

path

If the software image is packaged within some form of archive format (e.g. tar or zip format) then this element can be used to indicate the exact location of the software image within the archive file.

<!-- note that aladin can be started via webstart -->
      <executable>
         <platform>
            ivo://net.ivoa.application/platforms#JavaWebStart
         </platform>
         <download>
            http://aladin.u-strasbg.fr/java/nph-aladin.pl?frame=get&id=aladin.jnlp
         </download>
      </executable>
      <!-- or downloaded directly-->
      <executable>
         <platform>ivo://net.ivoa.application/platforms#Java</platform>
         <download>
            http://aladin.u-strasbg.fr/java/nph-aladin.pl?frame=get&id=Aladin.jar
         </download>
      </executable>
      <!-- or even run as an applet -->
      <executable>
         <platform>
            ivo://net.ivoa.application/platforms#JavaApplet
         </platform>
         <download>
            http://aladin.u-strasbg.fr/java/nph-aladin.pl
         </download>
      </executable>
   </ri:Resource>
  

SoftwareLibrary Type

The SoftwareLibrary type is used to register software that is not executable, but can be used as a component to build other executable software. The only metadata that the SoftwareLibrary type has beyond the basic Application type is that of the library element which is of type ExecutionEnvironment and can thus be used to indicate the location and platform that a library has been compiled for.

Enumerations

In accordance with the guidelines laid down by [VR], there has been no attempt to create enumerated lists for cases where there list could not be closed (e.g. the set of operating system names will grow as new operating systems are developed). This means that the values of certain elements in a document instance will not be checked by even a validating XML parser, and validation that the element contents are allowed will have to be done by a separate process. This section will list the allowed values for those enumerations where appropriate and instance documents MUST use these exact strings to represent the same concept. These names are registered using the VOStandard schema [VSTD] as vstd:ResourceEnumList types, and the registry entries for the enumerations will be the definitive source for updates that occur after this document is published.

The procedure to add to these enumerations is to apply by email to the curators of the respective resources

Suggestions for Extension

Common Execution Architecture (CEA)

The VOCEA schema that is used to register CEA information [CEADM] is a good example of how the VOApplication schema can be extended. This has already been illustrated in the UML diagram earlier in this document.

Plastic

TBC

Appendix A: The complete VOApplication Schema

Note that this schema can be found on-line at http://www.ivoa.net/xml/VOApplication/v1.0 (i.e. the target namespace can also be used as a URL for the schema.) This location should represent the definitive source, the schema is only copied below for completeness of this document.

Appendix B: The complete source of the examples presented

The example instances of the the VOApplication schema show several features of how to use the schema to register applications.

Appendix C: Change History

This is the first version that has been made public - it is derived from wiki content.

References

[RFC 2119]

Bradner, S. 1997. Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, http://www.ietf.org/rfc/rfc2119.txt

[RM]

Hanisch, Robert (ed.) 2004. Resource Metadata for the Virtual Observatory, Version 1.01, IVOA Recommendation, http://www.ivoa.net/Documents/REC/ResMetadata/RM-20040426.htm

[VR]

Plante, Ray (ed.) 2006. VOResource: an XML Encoding Schema for Resource Metadata, IVOA Working Draft, http://www.ivoa.net/Documents/latest/VOResource.html

[VSTD]

Harrison, Paul. (ed.) 2006. VOStandard: an XML Encoding Schema for IVOA Standards, IVOA Working Draft, http://www.ivoa.net/Documents/latest/VOResource.html

[CEA]

Harrison, Paul. 2006. A Proposal for a Common Execution Architecture , IVOA Working Draft, http://www.ivoa.net/Documents/latest/VOCEA.html

 

[CEADM]

Harrison, Paul. 2007. CEA Application Model: A model and XML Encoding Schema for Applications in the Common Execution Architecture, IVOA Working Draft, http://www.ivoa.net/Documents/latest/CEADM.html

 

[xml]

Bray, Tim, Paoli, Jean, Sperberg-McQueen, C. M., Maler, Eve, Yergeau, Francois (editors) 2004, Extensible Markup Language (XML) 1.0 (Third Edition), W3C 25-Apr-2007 15:44/TR/REC-xml

[schema]

Fallside, David C., Walmsley, Priscilla (editors) 2004, XML Schema Part 0: Primer Second Edition, W3C Recommendation 28 October 2004, http://www.w3.org/TR/xmlschema-0/

[ID]

Plante, R., Linde, T., Williams, R., Noddle, K. 2005, IVOA Identifiers v1.1, http://www.ivoa.net/Documents/REC/Identifiers/Identifiers-200505XX.html.