Results from a Community Workshop
sponsored by
NASA's Living With a Star Program
27-29 October 2004
Marriott Hotel, Greenbelt, MD
1 January 2005
Workshop organizers and focus
group leaders
D. A. Roberts, GSFC
Table of Contents
Executive Summary
I. Why "Virtual Observatories"?
III. Current Activities as Starting Points
IV. Products, Services, and Resources
V. Overview of the Components of the Data Environment
VI. Basic Data Access and Services: Data Providers and VxOs
VII. Data Models and Registries
VIII. Services Beyond Finding and Accessing Data
IX. How Do We Know It Worked? (Metrics)
X. What Can We Do Now?
XI. Summary and Vision
Appendix: Block Diagrams of Some Existing or Proposed VOs.
Executive Summary
The new challenges in solar and space physics, including linking solar phenomena to human consequences as studied in NASA's Living With a Star program, will require unprecedented integration of data and models across many missions, data centers, agencies, and countries. Accomplishing this requires a coordinated effort to link data and service providers to scientific users through software that uses nearly universal language descriptions to give a uniform face to an underlying heterogeneous and distributed set of resources. Such three-part entities—front-end software linked to repositories and services through "gateways" or "brokers"—represent a generalization of the ideas behind the "virtual observatory" (VO) intended to give astronomers virtual access to all observations of the sky. This workshop, held in Greenbelt, MD on 27-29 October 2004, brought together nearly 100 space and solar physicists and technologists, along with Earth scientists and astronomers, to come to basic agreements on how to proceed to build a robust data environment for future space and solar physics research based on the virtual observatory paradigm. Some of the main ideas had been in the community by other names for over a decade, but new Internet connectivity, greater emphasis on global problems to be solved with multiple spacecraft and models, and increased support by agencies has brought us to a point where the need and means are clearer for realizing an integrated data environment.
The workshop consisted of a set of plenary talks (available on a link at http://lwsde.gsfc.nasa.gov, which also includes many presented posters and other background) that gave an overview of current efforts and issues, followed by 1-1/2 days of working groups and plenary sessions designed to clarify and elaborate the vision and plans. The above three-part VO structure was followed by the existing VOs, although the details differed. There are beginnings of integration of the current efforts, and the connections are becoming more direct. The workshop agreed on the need for agreement on at least a core of common "data model" terms, such as presented by SPASE and EGSO, although all agreed that specific communities, represented by "VxOs" ("x" being the community), would have some terms specific to their needs. Data models are much farther along in describing data products than services. The roles of the resource providers and the VOs were delineated at the workshop, with VxOs being mainly responsible for uniformity of access across providers and for higher level services and the providers for basic data quality and access, although the VO data environment should provide considerable flexibility in what tasks are performed by which parts of the system. It was agreed that a level of metadata management services, generally invisible to users, would be essential. Science services, such as format and coordinate translations, visualization, and higher-order queries, were seen as highly desirable but not part of the central core services which consisted of finding and accessing resources in uniform ways.
It was agreed that the current VO groups should continue to coordinate their efforts. In the short term this will be on an informal basis, but longer term there should be a coordinating group consisting of VO representatives (scientific and technical) and users from the scientific and community. Initially these may be agency specific groups, but interagency and international coordination, which is a natural outgrowth of much current work, will be needed and should continue to be part of workshops and other efforts. While the data environment is becoming established, data and service providers can be describing their resources in uniform data model terms and providing feedback to groups working on the data models; making data and services machine-accessible with APIs or other means as current resources allow; and linking to current VOs or making VxO alliances. In addition to continuing to coordinate their efforts, the VOs should seek community feedback on current VO interfaces and other issues.
The broad outlines of the disciplines of solar and space physics are now well established. The significant problems in these areas—which include the physics of fields, plasmas, energetic particles, dust, and gases from the interior of the Sun to the outer reaches of the heliosphere, as well as down to the surfaces of solar system bodies—frequently involve relating many different datasets with large data volumes. These data are located at sites distributed worldwide, stored in a variety of formats, and accessible through a wide variety of interfaces. Much of the data are now online, although significant datasets still reside offline on tapes or CDs and some are not produced on a regular basis. The preparation of even online data for a particular scientific study often poses a sufficient impediment that the study is not undertaken. Days or weeks may be spent reformatting or combining datasets, and broad exploratory studies can involve more work preparing data than in browsing for relationships. Models are even more difficult to incorporate in most cases, but they can be essential to an integrated view.
In short, success for Sun-Solar System Connection studies (to use the current NASA terminology) will involve an unprecedented integration of contrasting empirical data sets, as well as an integration of observations with models and simulations. Given the work already expended in making resources available, a further integration should be built on the current data systems such as those produced and maintained by national or other data centers and by many particular spacecraft or instrument-based facilities. The resulting data environment must include a sufficient knowledge of formats, spacecraft metadata, and models to allow a scientist to work with physical quantities rather than, say, CDF or FITS files from a specific satellite. Ultimately, users should be able to view simultaneously multiple data sets and/or models in 3-D along with panel plots and images or movies, treating all spacecraft or observatory data in a uniform manner. The ideal would be to have the data and other resources appear to be locally held and uniformly available to a set of applications that are easy to use and that could be linked to perform more complex analysis. Those familiar with applications such as IDL would be able to load data from distant sources transparently so they can use the tools they have developed.
There are a number of problems to be addressed to reach the above ideal, and a stepwise approach that allows continual upgrading will allow us to have benefits now while eventually arriving where we would like to be. The steps need a context, and this workshop was intended to produce general agreements on the overall architecture of the data environment that will allow us to proceed and will help funding agencies direct their resources efficiently. The workshop had a day of overview talks on the status of the more advanced projects followed by 1-1/2 days of focus group and plenary discussions of the issues. (The presentations and much other background material including links to many current efforts are on the Web; go to http://lwsde.gsfc.nasa.gov.) The results of the focus groups, as modified by the group as a whole, were summarized and unified into this report, which was then iterated with the participants and a much broader selection of the community. Over 100 people participated in the workshop representing many countries and agencies.
The idea for a unified space and solar physics data environment is not new, and was discussed in detail over a decade ago at a NASA-organized workshop at Rice University in 1993 that tried to define a Space Physics Data System (SPDS) (McGuire and Galiardi, 1993; see the links to documents on the LWS DE site). The Rice workshop concluded that the SPDS should be a distributed data system designed, developed, and operated by scientific users of space physics data that maximally uses existing facilities. The NASA Master Directory should indicate where all SSSC data reside and give an adequate description of the holdings to help researchers decide their relevance to their work. Metadata should include the instrument, satellite, format of the data, a timeline of instrument and satellite events, and the location of the ephemeris. The critical system functionalities identified for SPDS were: the delivery of self-documenting data; the existence of a matrix of translators between several standard formats; and a network-based capability for browsing and examining inventory records for the system's data holdings.
The effort to produce a SPDS did not generate enough community support and attendant funding to be fully realized. Since then there have been some efforts to revive the SPDS ideas, but the major change has been that the Internet and tools to use it efficiently have transformed the possibilities for such a system. Data centers have exploited this to unify many datasets and services in tightly coupled systems. These developments combined with the need to address broader science questions have led to many recent high-level calls for an integrated approach to the SSSC data environment. For example, the Sun-Earth Connection (SEC) Roadmap [Sun-Earth Connection Roadmap: http://sec.gsfc.nasa.gov/sec_roadmap.htm, Sept. 2002] states that "…a technology program is needed that develops the tools necessary for systematic and automatic access to large and distributed data sets and the ability to synthesize quite disparate data sets. To address all of these diverse requirements, early investments in information technology will be a high priority, in particular to promote the system understanding sought by LWS and STP missions." Similarly, a high priority Vitality Program was proposed by the Space Studies Board of the US National Academy of Sciences in "The Sun to Earth – and Beyond: A Decadal Research Strategy in Space and Solar Physics (2002)." They called it the Solar and Space Physics Information System, defined as a "multiagency program for integration of multiple data sets and models in a system accessible by the entire solar and space physics community." This was ranked above Guest Investigator, SEC Theory, and Targeted Research and Technology programs.
Another difference between the current situation and that in 1993 is that there are significant advances being made by a number of groups in providing the first steps along the path to an integrated data environment. NASA has funded a few major and many smaller efforts to work on these ideas. These efforts have coalesced around the idea of a "virtual observatory," a term initially coined by a group of astrophysicists to describe the idea of being able to examine any patch of sky using the collected observations in all wavelength ranges by connecting to the sources of these observations on the Internet. In the US this became the National Virtual Observatory (http://www.us-vo.org/), but the effort took root in many places and has grown into an International Virtual Observatory Alliance (http://www.ivoa.net/). A number of people seized the idea of uniting disparate observations from dispersed providers, thereby generalizing the term "Virtual Observatory" to apply not only to Astrophysics but also to Space and Solar Physics and to Earth Sciences as well (e.g., the ECHO project; http://www.echo.eos.nasa.gov/). The original meaning of the term will be realized in our community when the space and solar physics data sources and models are linked to 3-D visualization that will allow the user to see the fields, plasmas, and particles, whether measured remotely or in situ, evolve in the physical domain where they were measured and calculated. Thus we arrive at the present with a vision for Space and Solar Physics that involves a set of interrelated VOs to enable the next science advances in these fields.
The above discussion leads to a definition of a Virtual Observatory (VO) as a suite of software applications on a set of computers that allows users to uniformly find, access, and use resources (data, software, document, and image products and services using these) from a collection of distributed product and service providers. A VO includes registries based on a metadata model, front-end applications, and connections to data providers.
A VO is a service that unites services and/or multiple data providers, with a "VxO" doing this for community "x." The set of such VO services should be made such that they can be linked to include other services, with the resulting data environment being flexible, extensible, and as simple as possible so that the overall system remains inexpensive and easily maintained. Each VO should be accessible not only to a browser application, but also to other VOs and applications through appropriately designed Application Programming Interfaces (APIs) or other means. (An API is a set of routines that can be used in other programs to simplify a set of tasks; in this case, typically, remote procedure calls using, for example, the Simple Open Access Protocol or SOAP.) Standards for the required protocols and descriptive languages should be motivated by utility and not by fiat. More generally, while too much duplication is wasteful, the experience of a number of groups has shown that top-down imposition of structure for such a diverse endeavor, however tempting, tends to result in systems that are not well-accepted, and that "market" forces should be allowed to determine the best directions for the efforts. In some cases this may involve community-based agreements on standards and architectures that enable the desired connectivity.
Coordination of efforts is essential and should come through frequent interchanges between groups, including through a coordinating group of representatives of the VOs and the user community. The funding agencies would exercise control through selection of competitive proposals for VOs and related services and organizing both coordinating and advisory working groups as they see the need. Initially these efforts would probably emphasize agencies in specific countries, but we foresee that an international organization will be needed, as has occurred in the astrophysical community. The electronic Geophysical Year (http://www.egy.org/) may help to provide some structure for this.
VOs should make “standard” scientific research much more efficient. If the new paradigm is successful, even the PI teams should be tempted to use VOs for looking at their own data. VOs, to be accepted, must improve on existing services (Mission and PI sites, CDAWeb—http://cdaweb.gsfc.nasa.gov/, etc.) by providing greater breadth and convenience such as by removing impediments imposed by the underlying format or coordinate system of a dataset. VOs will not replace the data centers and other providers, but will use them in new ways. Often specific provider sites or "community" VOs will offer some services that will not be accessible by higher level VOs, and this should be expected and encouraged.
VOs should also enable new, global problems to be solved. Being able to access diverse datasets and services should allow researchers to rapidly gain integrated views from the solar origin to the terrestrial effects of an event. Wide-ranging search capabilities will allow a user to find data related to any particular observation. Ultimately VOs and associated services should enable us to answer “higher-order” queries such as “Show me the data from cases where a large CME and its effects that was observed by SOHO was also observed in situ in the heliosphere, in the Earth's magnetotail, and in responses in the
magnetospheres and ionospheres of any planets.”
High-quality, well-documented, publicly available data and well-documented, easy-to-use tools to interpret them are the core of the data environment. Although this will not be the focus here, it is essential that there continue to be support for bringing previously unavailable products up to this level where there is a perceived need. Techniques for automated data reduction are essential, and could be encouraged through programs such as NASA's AISRP. An open-data policy has become expected at NASA (see http://lwsde.gsfc.nasa.gov/Rules_Revised20030327.html) and in some other areas, but is still not universal. We believe it is the experience of nearly all data providers that having a larger group use their data is good for the data and for the support of their efforts by funding agencies.
Equally important, but also not the present focus, is a long-term active archive plan that will insure the correct, independent use of data, software, and models after PI-team expertise is no longer available. This will be addressed, in part, through Project Data Management Plans for new missions, but legacy data will also be important, and the emerging idea in NASA for "Resident Archives" to keep data close to the science teams for some time after mission termination should help the overall process.
The discussion below will mention a number of currently funded activities that are working within the framework of VOs. Detailed descriptions of these can be found at the links from the LWS Data Environment site mentioned above. Here we provide a brief overview to give a sense of what is being done and to make the subsequent sections more easily understood.
The Virtual Solar Observatory (VSO; http://virtualsolar.org) has focused on delivering image data files from many observatories at different locations using a unified interface. They deliver FITS files from SOHO, Yohkoh, and a number of ground-based observatories. They have simple user interfaces and plans for others as well as the beginnings of APIs, and are developing easy ways for others to "join" the VSO. This VO is the original "small box" building block of a VxO –based data environment.
The Virtual Space Physics Observatory (VSPO; not a "VxO"—see http://vspo.gsfc.nasa.gov/) currently provides access to a broad range of space and solar physics data, models, plots, indices, and images from over 40 repositories and 35 observatories/spacecraft using the interfaces provided by the repositories (a "big, shallow box"). The registry uses the SPASE data model (see below), and the system is layered similarly to VSO. VSPO now allows file retrieval from some providers (making the "box" deeper) using SOAP and other interfaces, and it will use the VSO API to access solar databases.
The European Grid of Solar Observations (EGSO; http://www.egso.org/) is a grid-based data and service access system that has included more capabilities for event driven searches than the VO projects above. They have a number of prototype services (see http://www.egso.org/demo/) including a Query Builder, access to many Solar Event Catalogues, and a Solar Features Catalogue. They have spent considerable effort on a data model (available on their site) that includes space physics terms in addition to a detailed solar physics vocabulary.
The Collaborative Sun-Earth Connector (CoSEC; http://cosec.lmsal.com/) will unite services of all sorts; CoSEC is currently focused toward solar applications using SolarSoft—a mainly IDL-based library of analysis routines (http://www.lmsal.com/solarsoft/) —but the tools are general. A nice example of its use is the SolarSoft Latest Events web page (http://www.lmsal.com/solarsoft/last_events/) that links many real time sources of data and analysis routines to give a detailed view of the current state of the Sun and heliosphere.
The Virtual Heliospheric Observatory (VHO; http://vho.nasa.gov) is beginning to unite a number of distributed repositories for heliospheric data. They will use an (extended) SPASE data model and SOAP interfaces. They are working hard at assuring the data are well calibrated and complete for improved solar wind studies. As part of this, the ACE Science Center is developing direct machine access APIs.
Central to the success of the data environment is a uniform set of terminology to describe products and their sources. EGSO has been making major efforts in this area, and VSO has developed a simple data model for their needs. The SPASE (Space Physics Archive Search and Extract; http://www.igpp.ucla.edu/spase/) collaborative, consisting of scientists and software developers from a number of US and European institutions, has been focusing on formulating a data model that will unify other efforts. It is now funded by NASA to also use the data model in the context of a number of existing data repositories, and is working to develop a unified approach to the data environment. A working draft of the SPASE data model is available for comment (see http://www.igpp.ucla.edu/spase/data/model.pdf).
Data centers such as the National Space Science Data Center (NSSDC; http://nssdc.gsfc.nasa.gov/) and the related Space Physics Data Facility (SPDF; http://spdf.gsfc.nasa.gov/dev_services.html), NOAA National Geophysical Data Center (NGDC; http://spidr.ngdc.noaa.gov/spidr/index.html), and the French Centre de Données de la Physique des Plasma (CDPP; http://cdpp.cesr.fr/english/), as well as the Planetary Data System (PDS), have software in various stages of development for broadening access to their data. The SPDF, in particular, has produced SOAP interfaces to their online space physics data holdings (CDAWeb) and orbit information (SSCWeb), and the latter has an associated OrbitViewer tool (http://sscweb.gsfc.nasa.gov/tipsod/). Those interested in building VOs will also be interested in work in other sciences such as Astrophysics (e.g., http://www.ivoa.net, www.us-vo.org, www.astrogrid.org) and Earth Science (e.g., http://opendap.org, www.echo.eos.nasa.gov).
The idea of a "product" is frequently used in the context of VOs and other data systems. The Planetary Data System, CDAWeb, SPASE, VSPO, and most Earth Science data systems use this as a central idea, but it is not currently as central to VSO, and EGSO takes a more general view. Solar physics, in particular, has a long history of observations as individual investigations of a particular phenomenon rather than uniform time series of images, but with the advent of missions such as SOHO, Yohkoh, and SDO, the product idea is becoming more natural in these areas as well.
Products are sets of things produced that have common characteristics along with required metadata that allow the product to be useful. Many types of products are possible, but numerical data is a central type for VOs. It can sometimes be difficult to determine which sets of data should be considered an individual "product" of this type. The simplest idea, which works for the vast majority of cases, is to define a Numerical Data Product as a set of files (either "static," i.e., pre-made and resident on a disk or other medium, or "dynamic," i.e., made on-the-fly from an underlying set of files) that differ only in the time of the observations in them. Such a product would typically extend for the entire life of a mission. A set of FITS images of the solar disk in a particular wavelength from a particular observatory would be an example, as would a set of HDF files providing tables of in situ vector magnetic field measurements along with positions and time from a particular spacecraft at a specific time resolution. A data provider may offer the ability to retrieve subsets in time or in physical quantity (only the x-components, …), but the product is the complete set. For some dynamic products, more than one product could be based on an underlying set of files. An example would be that an instrument that measures particle distributions in space could be used to produce "moment" files, pitch-angle-distribution files, and full-distribution files, but these need not be mixed. (These sets could be made for all the measurements, resulting in three static products.) In general, the detailed specification of products can be left up to the providers.
The main utility of the product idea is that it provides entities that can be registered for finding and pointed to for access. Each provider can determine names for the products, and broader sets of product IDs can be made from these by VOs that desire them. The (extreme) alternative to identifying products is to refer to a particular file or set of files by a set of values of terms in a data model; this should always be possible, but it is then more difficult to keep track of what is available and how to access it. In this approach, aggregations of basic files ("granules") are formed only through the commonality of a set of metadata terms chosen. In contrast, the organization in terms of products can also make it easier to do iterative searches; one can find a product, and then subsets of it, rather than generating file lists as the only possible result. Having this higher level of organization helps in providing detailed availability information as well. One disadvantage of a product orientation is that it can take more work to produce cross-product aggregations such as which granules are associated with an event. In what follows, we will refer to products in the above sense, although the more flexible aggregations of granules linked by term values are also consistent with the discussion below; at times each case will be noted. In EGSO terms, "Catalogues" can keep track of either granules or products, depending on the provider.
In addition to numerical data, the types of products that are often distinguished include images (typically JPEGs or GIFs of numerical data for an image or of line plots), software (including tools for analyzing numerical data), models, event lists (or catalogues), and documents. Each of these can have a different set of descriptive terms, but there will be some characteristics that are shared between types.
We will take "service" to mean a procedure executed by a computer that can be called from remote machines and that will perform operations on products or the output of other services. This would include such things as converting file formats, transforming coordinates for a dataset, displaying a FITS image, and plotting the data in a generic CDF file. The distinction between products and services is not always clear in that, for example, delivering subsets of data or producing dynamic data products meet the definition of "service." This ambiguity need not be resolved, and some developers see all VO and data provider interfaces as services. In what follows, we will distinguish the basic finding and accessing of data from other services, in that the former two functions are essential to a VO. We will use the term "resources" to refer to products and services collectively. Note that software to perform the functions of a service may be available for a user to download and use locally; making this easy is also a natural function of VOs.
Most people who have dealt with the problem of the architecture for an interrelated set of VOs have come to the same conclusion about the architecture for them. In simple terms, repositories ("active archives," "providers") are connected to user applications ("front-ends") through a middle layer (a "broker" or "gateway") that allows uniform queries and access to the resources due to their being registered in a common language (using a "data model"). This three-part structure can take many forms in detail, but the common elements are listed below. Subsequent sections detail further aspects of these components.
The major components of a VO environment are:
Web-based, machine/application-accessible (“queryable”) active archives of data from spacecraft or models. Three existing ways to make data accessible are (1) through a well-organized ftp site, (2) using extended http get or post as is done in OPeNDAP (an Earth science VO; http://opendap.org/), and (3) with a SOAP service, as is now implemented by CDAWeb. The SOAP methods allow more flexibility of access to the data provider services. The most important point is to have access to the repository resources through a means that allows applications (including web applications) to perform remote procedure calls.
Registries of products and services. These will provide a uniform description of products and services across the community or in a subcommunity, and will be based on a data model (a set of terms and their relationships that capture the essential concepts of a given domain) such as those of SPASE and EGSO. There will be a need for specialized terms for some particular subfields or datasets, but the attempt should be to have as much uniformity as possible. The SPASE and EGSO models start from basic descriptions of the sources and types of products and from fundamental physical quantities in an attempt to insure generality. The differences between the various models will be worked out through coordinated efforts.
Front-end applications. These represent the portals through which users access the data and services. The simplest are Web-browser-based extensions of existing repository-specific tools that allow the user to narrow a search for products based on values of keywords submitted through various Internet protocols such as SOAP. It will also be possible to have direct streaming of data into applications such as IDL, as is now done in some cases by SolarSoft and OPeNDAP, and by SDDAS (a data system based at SWRI; http://www.sddas.org/) as part of its design. The front end is what the users see, and thus is crucial to success.
Brokers (or "gateways") to connect the repositories to front ends using the information in the registries. Having this extra layer between the user and data or services makes it possible to give the user a uniform means of access. With easily Web-accessible data and good registries, it will be possible to have a number of these with varying scope (“VxOs”), some of which will use others to extend their reach. Brokers translate queries in Data Model terms into requests to specific repositories in the language of the repository. Each VxO or other VO should have an API or equivalent means to make it seem like a resource provider to users or other VOs.
Services that will allow VxOs to manage their metadata, and, for example, will allow users to rapidly and easily put data into useful form, no matter what the underlying format. Ideally, there will be generic software that can interpret a variety of formats and produce listings and plots (as in CDAWeb or SPIDR, for example, but generalized) as well as a library of routines that will provide value-added features for each data product (as is done by SolarSoft for many solar observations). Visualization software for data and models will also be very helpful. These services may be Web-enabled and chained, as done by CoSEC.
Higher-order search capabilities. Ultimately we would like to be able to pose questions such as “When was there a spacecraft in the magnetopause and gathering data when a CME was arriving?” One important approach to this type of problem is to provide uniform access to Event Catalogues (or Event Lists; EGSO is making considerable progress on this) that can include detailed data availability listings for a product as a special case. Other important aspects will be model-based spacecraft location determinations (as in SSCWeb), and the use of survey-level data (e.g., OMNI data) to find, for example, regions of low solar wind density by direct examination of the data. Again, these capabilities can be Web-service enabled such that intervals found from Event Catalogues can be passed to the brokers to find specific data.
We see a fairly natural division between the roles of data providers and VxOs, although the nature of VOs is such that the boundaries are flexible. In particular, the major roles for the data providers should be:
Support a communication mechanism – should support a standards-based messaging system (e.g., ftp, http, SOAP, XML)
Document the validation process.
Provide quality information (flags).
Maintain careful versioning including the processing history of a product.
For their part, the VxOs should:
Identify relevant data sources and appropriate repositories.
Allow queries that yield data granules or pointers to them.
Provide a user interface to access resources both through an API (or equivalent machine access) and a web browser application.
Handle a wide range of provider types, as needed.
• Understand the data needs of its focus area:
Recruit potential new providers.
Provide support and "cookbooks" for easy incorporation of providers.
Help to assure high data quality and completeness of the product set.
Resolve issues of multiple versions of datasets.
• Provide documentation for metadata:
Set standards for metadata and query items
Assist providers, and review metadata.
Maintain a global knowledge of data availability.
Possibly maintain collection catalog metadata.
• Provide an API or other means for the VxO to appear to others as a single provider.
• Potentially provide value-added services (can be done by providers or elsewhere):
Data Subsetting
Averaging of data
Filtering
Data Merging
Format Conversion
• Provide access to event lists and ancillary data.
• Collect statistical information and community comments to assess success.
VxOs could vary considerably in their complexity. Some might want to physically aggregate data (e.g., ground magnetometer measurements could be brought to a common repository) and others would hold it in a more distributed way. A VxO might decide to collaborate with another such group for the actual provision of its data. Thus, a new VxO group could work with a VHO group to extend the VHO product registry to include their data providers rather than reinventing the broker software. The level of services delivered could vary considerably as well. Ultimately, it will be the selections of proposed ideas that determine the fabric of the data environment, although for success all groups should be committed to providing easily used access and services for the others.
Data models are essential if we are to find and use products across disciplines and missions without having to know a new set of search words and variable names for each case. That said, there are real differences between different subfields and instruments that make it difficult to have complete uniformity. An important issue is the extent to which it is possible to have such uniformity. One result of the workshop is to encourage the various groups working on data models to work more closely. At the highest level of description, there is considerable agreement between various data models on those aspects of a product (or granule) that are not dependent on its information content. These "elements" (or "classes" in ESGO terms) are very useful for finding resources, and include: the Observatory/Spacecraft responsible for the observations, the Instrument Name(s), the Data Provider (or "Repository" or "Archive") that holds and delivers the data, the Instrument or Observatory Region (in general terms, e.g., magnetosphere, ground-based), the Observed Region (same as Observatory Region for in situ measurements, but not for remote sensing observations), and the Time Span (either for a product or a granule). At this level there are a number of elements that typically would not be used for searching, but that are essential for use such as Contact information (person and/or group responsible for obtaining and preparing the data), File Format, Availability (online, on tapes, etc.), Access Rights (restricted in various ways or open), URL for data access, and Caveats for the use of the data. The categorization of such elements is not essential, in that they need not be hierarchically related to other elements and can stand on their own.
Beyond the above broad characterizations of products or basic collections of granules there are various levels of aggregation and description. To aid searches it can be useful to distinguish, for examples, types of measurements (field, plasma, particle distributions, dynamic spectra, etc.). Event and feature catalogues may be regarded as types of products that contain metadata about the times of occurrence of specific features (bow shock crossings, CMEs, active regions, …) with pointers to datasets and products that are relevant to these. At the lowest level, it is possible to document every granule in a product with its corresponding metadata. Such detailed catalogues, if well indexed, could aid in determining product availability and using specific files. The metadata about the content of granules may be relatively simple, giving a product-wide indication of what was measured ("full-disk images of the Sun in H-alpha"), or it may involve identifying all the variables ("columns") in the files of a product including the quantity represented (density, energy flux, …) for a particular entity (photon, magnetic field, electron, …), with units and perhaps the typical graph label for each. How the metadata terms used for each of these levels of description will be organized and used in searches and retrieval were points of considerable debate; this issue need not be resolved universally, and different VOs may make different implementation decisions based on the services they support.
As with many aspects of the data environment envisioned here, where various metadata are registered (entered into lookup tables) will be flexible. As mentioned above, in some cases granule metadata will reside with the data providers, while in others at least some version of it will be held more centrally. However, the experience of some groups likely implies that continually querying all providers for what products they have is inefficient, and some degree of centralization is helpful. VSPO is centralizing metadata from a very broad range of providers in what might be called a "product clearinghouse"; experience will tell what is gained and lost with this level of integration. Depending on the specific architecture of a VxO, it might have more than one registry, for example, one for search, another for access, and another for services. Updates of registries can be made available to other groups either through the sending of metadata by the registry service or through the querying of that service, or both.
Two areas have yet to receive much work, namely metadata for services and for models. Here "models" is taken to mean either physics-based or empirically based predictive schemes (equations or computer programs based on equations or empirical input) that are intended to provide some level of understanding of a set of phenomena. If the set of models and services remains fairly small, then finding them will not be a major problem. Some of the terms used for numerical data will be appropriate, such as the terms for physical domains and providers, but we need to have more experience with what people will want to be able to generate the right metadata for categorizing models and services. Similarly, event catalogues, while they are becoming more numerous and useful, do not have agreed upon formats or metadata.
Virtual Observatories can be viewed as a simple case of a more elaborate computing environment. In this context they consist of three components: A set of well-defined services or tasks; a sequence, or workflow, for executing those tasks, and a manager for the user to interact with both. In the VO case, the minimal set of services are locating and delivering data for the user from a set of data sources, and the workflow is a simple three-step process: find, review, and deliver. Several of the VOs are considering more complex sets of services with correspondingly more complex workflows. There have also been discussions of incorporating third-party services. Since VOs are still in development, we do not yet know what the best combination of services and workflows will be, so we should consider the VO model in the more general environment to assure that it can adapt and evolve towards an optimal solution.
We will address two questions: what sort of services will be needed, and what environment should be established to encourage their development and adoption by the space science community? As with the VOs themselves, a marketplace approach should be used as much as possible to determine the types of services.
As for the architecture, there must be some agreed standards so that developers and users can easily share their services. The architecture should include middleware for services such as that being developed by the CoSEC project. It should use existing technologies and tools when it is possible and when it reduces cost and helps to insure compatibility with future standards. Grid and web-services technologies and other evolving infrastructure tools should be adopted as appropriate. Service applications could be downloaded or repository provided (e.g., graphics and subsetting), in addition to being web-service accessible (e.g., SolarSoft via CoSEC), but in all cases, they ideally should be advertised in conjunction with the resources they use.
The coordination and facilitation of services, tools and people will require the maintenance of an advisory group, preferably a grassroots working group or user forum. It would coordinate service development, review emerging tools and standards and report their progress to the appropriate funding agencies.
Several services are natural candidates for inclusion. Some involve infrastructure, which would be largely invisible to science users but could be essential to the overall operation of the VO system; others are things that scientists would incorporate into their own workflows. In what follows, the infrastructure services are further sorted to identify those that were thought to be critical to the overall success of the VO services, those that would be important to its adoption by the community and its growth, and those that would be desirable if funding and technology permits.
Critical Infrastructure Services
Š Publishing/registering service for datasets and services
Š Metadata management
Registration
Browsing
Updating
Query
Important Infrastructure Services
Š Session/Persistence services, i.e. user history/logs
Š Data transport services, i.e. multiple file transfer
Š Metadata services
Validation
Discovery
Desirable Infrastructure Services
Š Display
Š Metadata translation services
Š Authentication services
Š Authorization services
Š Monitoring service
Š Versioning service (version of the service itself)
Š Scheduling and resource allocation services
Š Directory ("phonebook") of services
Š Workflow services
Š Interface builder/configuration services for interfaces to portals
Š Groupware services to enable collaboration
Science Services
Š File format conversions
Š Coordinate transformations
Š Software for visualization of datasets
Š Software library for basic analysis
Š Data readers
Š Metadata services
Extraction
Aggregation
Annotation
If the VO development is to be "market driven," we have to be able to measure what the users think of the various efforts. The simplest measure is "web hits," but this does little to measure true interest and utility. The ultimate measure of success is that the improvements in the data environment contribute substantially to new scientific results, and especially to fundamental advances. Measuring this can be difficult depending on the degree to which users acknowledge and document in publications the utility of the tools. We conclude that it is primarily up to each group to propose and carry out a plan for documenting utility. This can include surveys, literature searches, web form feedback, and gathering testimonials. (One test, proposed only half in jest, it to see how much e-mail is generated by turning a given service off for a day.) There will never be a fully objective way to measure user interest, but it should not be difficult to demonstrate the major successes.
There are some funded efforts in the community, but others who want to "join" or contribute can be doing some things now based on even small existing resources. The involvement of data providers is key to progress at this point. Some of the things they can do are:
Of course, existing VO groups should continue to talk to each other and to work toward evolving useful standards for metadata and protocols. It will be especially important for those working on data models to rapidly achieve some level of closure so that the community has a solid basis for proceeding. The funded VO groups are developing APIs and "cookbooks" for joining with their efforts, and are increasingly reaching out to the community for comments and criticism. We would especially encourage creative approaches to user interfaces, as these are crucial to utility. We hope that the space and solar physics communities will try the new tools and let the developers know what works and what needs changing. New ideas, even when good ones, take time to be accepted and to show their full potential. We can also hope that as we begin to show success that funding agencies will increasingly see the need for support for both development and maintenance of the new data environment.
We believe the Virtual Observatory approach to the space and solar physics data environment that is proposed here will satisfy the need for finding, accessing, and using solar and space physics data that is expressed in many reports in a way that can be easily extended as data providers add their services and that will scale well with increasing use. The community agrees on the outlines of the basic architecture of what is needed, and it now becomes a matter of bringing existing and proposed VOs and services to a level of utility where we can see what works best. The workshop endorsed the idea of having subfields organize their data and make them available through VxOs that can communicate with other VOs using a common language and communication protocol as much as possible. How the subfields are organized would be determined by the community and the proposals they put forward.
Ten years from now, we would like to have a data environment in which sharing and trading of resources between communities is commonplace. Some resources such as, perhaps, storage and various kinds of processing may be outsourced to specialty industrial or other group suppliers on a highly interconnected Grid. Many more operations will be automated, including aspects of data processing, registry updating, format translation, and other "mundane" tasks. Investigators should spend very little time finding and preparing resources, leaving most of their time available to determining relationships between and mechanisms for the fundamental phenomena we wish to study. Enabling tools should become more practical when, for example, Grid software is packaged as standard within Linux, Windows, etc., and integrated into IDL and other applications. We believe that the idea of Virtual Observatories will provide the framework for this vision to be realized.


N-dimensional datasets (astropy.nddata
)¶
Introduction¶
astropy.nddata
provides the NDData
class and related tools to manage n-dimensional array-based data (e.g.
CCD images, IFU data, grid-based simulation data, ...). This is more than
just numpy.ndarray
objects, because it provides metadata that cannot
be easily provided by a single array.
Note
The NDData
class is still under
development, and support for WCS and units is not yet implemented.
Getting started¶
An NDData
object can be instantiated by passing it an
n-dimensional Numpy array:
>>> import numpy as np
>>> from astropy.nddata import NDData
>>> array = np.zeros((12, 12, 12)) # a 3-dimensional array with all zeros
>>> ndd = NDData(array)
This object has a few attributes in common with Numpy:
>>> ndd.ndim
3
>>> ndd.shape
(12, 12, 12)
>>> ndd.dtype
dtype('float64')
The underlying Numpy array can be accessed via the data
attribute:
>>> ndd.data
array([[[ 0., 0., 0., ...
...
Values can be masked using the mask
attribute, which should be a boolean
Numpy array with the same dimensions as the data, e.g.:
>>> ndd.mask = ndd.data > 0.9
A mask value of True
indicates a value that should be ignored, while a mask
value of False
indicates a valid value.
Similarly, attributes are available to store generic meta-data, flags, and
uncertainties, and the NDData
class includes methods to
combine datasets with arithmetic operations (which include uncertainties propagation).
These are described in NDData overview.
Using nddata
¶
Reference/API¶
astropy.nddata Package¶
The astropy.nddata
subpackage provides the NDData
class and related tools to manage n-dimensional array-based data (e.g.
CCD images, IFU Data, grid-based simulation data, ...). This is more than
just numpy.ndarray
objects, because it provides metadata that cannot
be easily provided by a single array.
Classes¶
Conf |
Configuration parameters for astropy.nddata . |
FlagCollection (*args, **kwargs) |
The purpose of this class is to provide a dictionary for containing arrays of flags for the NDData class. |
IncompatibleUncertaintiesException |
This exception should be used to indicate cases in which uncertainties with two different classes can not be propagated. |
MissingDataAssociationException |
This exception should be used to indicate that an uncertainty instance has not been associated with a parent NDData object. |
NDData (data[, uncertainty, mask, flags, ...]) |
A Superclass for array-based data in Astropy. |
NDUncertainty |
This is the base class for uncertainty classes used with NDData. |
StdDevUncertainty ([array, copy]) |
A class for standard deviation uncertainties |


Generate a trap for the fifth edition of a popular tabletop RPG! Select the average level of your party and how dangerous you want the trap to be.
Level must be an integer between 1 and 20.
Reset Form


GYAN MANTHAN
CODE HUNT
Rounds:2
Time Limit: 1 hour
This is a coding event with different level of challenges.
COLLAGE
Entries:- Solo
Auditions: Participants are required to click some photos and make a collage with a hidden message in it. And the best one collage maker will be winner.
PRATIBIMB
Team size:Maximum 2 members.
Rounds:1
Time Limit:1 hour
In this event participant have to do painting on partners face according to the theme.
POT POURRI
Rounds:2
Time Limit: 30 min
This event is based on group discussion. After completing discussion, judgement will be given and questions will be asked by the respective judges.
WASTE TO WOW
Team size:Maximum 3 members.
Rounds: 1
Time Limit:45 minutes
In this event participants have to create something with the help of waste materials only. The best creative team will be selected by the respective judges.
NATYARPAN
Team size: Maximum 10 members.
This event is based on Nukkad Natak.
ART OF START
Team size: Maximum 2 members.
Rounds: 1
Time Limit: 1 hour
In this event participants share their business ideas for startup.
AD MANIA
Team size: Maximum 3 members.
Rounds: 2
Time Limit: 10 min
In this event participants have to advertise some product or service as given to them.


We make and design quality and simply irresistible cakes tailored to your demand. Our cakes are made from quality ingredients which are rightly mixed in the appropriate proportion under an uncompromising hygienic condition to give you that sumptuous taste that will end your search for satisfaction.
We believe in your ideas and imagination, so we always seek your opinions and create your imagination. We advice our clients on various options ranging from cake types, designs, flavors, shapes and sizes in relation to taste and events. Our prices are consumer friendly and our cakes are delivered promptly because we value our clients.


| path |
required |
path denotes the url of your analysis page. For example, {"path": "/NLP-sentiment", ...}
defines that the sentiment page will show up if you route to
https://socialmediamacroscope.org/.../.../NLP-sentiment |
| title |
required |
title will be displayed on the top of an analysis page |
| imgURL |
required |
imgURL will be the icon for that analysis tab in the home page. |
| wiki |
not required |
this will be the url to redirect to after clicking "read more..." button located within the analysis tab in
the home page |
| introduction |
required |
this is the short paragraph describing the analysis in the home page. Long sentences can be break into segments and
SMILE will be able to concatenate them by space. |
| result_path |
required |
It defines where your output is stored on the remote storage S3 bucket. Note you only need
to provide a relative path, i.e. SMILE has already taken into account that which S3 bucket and under which user/session
the output will store. For example, in run time {"result_path": "/NLP/sentiment/", ...}
means my (username: cwang138) sentiment analysis
results will be stored under the path /SMILE/cwang138/NLP/sentiment/
|
| args |
required |
It is the ID of the input parameter, if your algorithm has no input parameters, you can simply
leave the value of args as an empty array. But it is very important that each value of the args must match the id of
html element. . For example: {"args": ["algorithm"], ...} means there will be one user input parameter and its id
will be "algorithm". This matches the part in the same config file which we will talk about later.
{
"get":
"containers": [{
"input": {
"type": "select",
"name": "algorithm",
"id": "algorithm",
...
},
}]
...
}
|
| custom_script |
not required |
The value of this entry should be the path of a custom javascript file, for example:
{"custom_script": "bootstrap/js/customized/analyses/view_classification.js", ...}.
Within this .js file you can add your own custom actions to overwrite
the current actions, or to add more effects to the frontend. |
| get |
not required |
| containers |
| input |
Input the actual input element, which requires a type, name, id and based on what type it is there will be more fields |
| buttonGroups |
represents the buttons you see by the end of the form. If your analysis just need
a simple Submit/Clear feature that POST all the form input to the backend, you should use the template.
|
| citation |
defines the citation block content you will see on the page. You need to decide which event triggers
which citation display. trigger_id is the element id that you want to listen to, for example, setting the "trigger_id"
to be "algorithm" means whenever I change algorithm, the citation blocks will toggle and change. text is the full text
content of a citation, condition is the condition to evaluate and decides which citation to show. |
|
|


Projects
A cloud-based platform which is SaaS and IaaS
Users can complex SPARQL queries on OWLs ontologies using WebPy
Support for Multi-Tenancy and Caching of frequent query results
Perform Instant Query or upload your own ontology and Queries
Automated VM Load prediction using Linear Regressive model and balancing using
Xen-API
Literature survey and analysis of various face detection and recognition algorithms.
Implemented of Face Detection, Tracking or Recognition for input streaming video using haar-cascade using OpenCV and Python (45+ fps).
Implemented PCA-LDA, ILDA for Face-Recognition on GPU using PyCUDA and Sci-Kit CUDA.
Developed Prototype of Library Application in Android Mobile Platform to make the job of students, faculty and Library admins easier.
Automated the process of generating various types reports for admin and higher authorities.
Used Google's Firebase to synchronize and save data.
Created a back-end Operating System to provide a platform for IoT Devices
Signal Handling for Alarms and Timers to provide communication among devices on socket level using POSIX Threads (Pthreads) API in C
Using P2P and Cloud architecture, total 9 computers mimicked actual devices to demonstrate Internet of Things
This project was inspired by Google's "Project Brillo" with OS "Weave"
Developed database for university which manages student related data across multiple colleges.
Used MySQL workbench.
Generated grades of each students through sql programming based on grade matrix of individual course stored in database. Also answered some complex questions related to students through sql queries.


IMMUNS Registration
Oh it seems you have encountered a {{number}} error. Please try again. If the error persists please contact your HOSPITALITY member and state what error has been encountered please, sorry the inconvenience.


§315-3 Contracts under agreement. True copies of all contracts made on behalf of the State pursuant to the Agreement shall be kept on file in the office of the Hawaii teacher standards board and in the office of the lieutenant governor. [L 1969, c 47, §3; am L 2004, c 21, §3]


Measurements¶
- class pyspeckit.spectrum.measurements.Measurements(Spectrum, z=None, d=None, xunits=None, fluxnorm=None, miscline=None, misctol=10.0, ignore=None, derive=True, debug=False, restframe=False, ptol=2) [github] [bitbucket]
Bases: object
This can be called after a fit is run. It will inherit the specfit object and derive as much as it can from modelpars. Just do: spec.measure(z, xunits, fluxnorm)
Notes: If z (redshift) or d (distance) are present, we can compute integrated line luminosities rather than just fluxes. Provide distance in cm.
- Currently will only work with Gaussians. To generalize:
- 1. make sure we manipulate modelpars correctly, i.e. read in entries corresponding to wavelength/frequency/whatever correctly.
- miscline = dictionary
- miscline = [{‘name’: H_alpha’, ‘wavelength’: 6565}]
- misctol = tolerance (in Angstroms) for identifying an unmatched line
- to the line(s) we specify in miscline dictionary.
Methods
- Measurements.bisection(f, x_guess) [github] [bitbucket]
Find root of function using bisection method. Absolute tolerance of 1e-4 is being used.
- Measurements.bracket_root(f, x_guess, atol=0.0001) [github] [bitbucket]
Bracket root by finding points where function goes from positive to negative.
- Measurements.compute_amplitude(pars) [github] [bitbucket]
Calculate amplitude of emission line. Should be easy - add multiple components if they exist. Currently assumes multiple components have the same centroid.
- Measurements.compute_flux(pars) [github] [bitbucket]
Calculate integrated flux of emission line. Works for multi-component fits too. Unnormalized.
- Measurements.compute_fwhm(pars) [github] [bitbucket]
Determine full-width at half maximum for multi-component fit numerically, or analytically if line has only a single component. Uses bisection technique for the former with absolute tolerance of 1e-4.
- Measurements.compute_luminosity(pars) [github] [bitbucket]
Determine luminosity of line (need distance and flux units).
- Measurements.derive() [github] [bitbucket]
Calculate luminosity and FWHM for all spectral lines.
- Measurements.identify_by_position(ptol) [github] [bitbucket]
Match observed lines to nearest reference line. Don’t use spacing at all.
ptol = tolerance (in angstroms) to accept positional match
- Measurements.identify_by_spacing() [github] [bitbucket]
Determine identity of lines in self.modelpars. Fill entries of self.lines dictionary.
Note: This method will be infinitely slow for more than 10 or so lines.
- Measurements.separate() [github] [bitbucket]
For multicomponent lines, separate into broad and narrow components (assume only one of components is narrow).
- Measurements.to_tex() [github] [bitbucket]
Write out fit results to tex format.


Home
Number Bases
Temperatures
Mass/Weight
Currency
Distances
Distance Conversion
Meters:
Feet:
Millimeters:
Miles:
Micrometers:
Centimeters:
Inches:
Yards:
Kilometers:


The Witcher 3 Wild Hunt
20 Aug 2018 - Cd Projekt Red
The Witcher 3 Wild Hunt is a 2015 action role-playing game developed and published by CD Projekt.
and is based on The Witcher series of fantasy novels by Andrzej Sapkowski. It is the sequel to the 2011 game The Witcher 2: Assassins of Kings. Played in an open world with a third-person perspective, players control protagonist Geralt of Rivia, a monster hunter known as a witcher, who is looking for his missing adopted daughter on the run from the Wild Hunt: an otherworldly force determined to capture and use her powers. Players battle the game’s many dangers with weapons and magic, interact with non-player characters, and complete main-story and side quests to acquire experience points and gold, which are used to increase Geralt’s abilities and purchase equipment. Its central story has several endings, determined by the player’s choices at certain points in the game.


Facilitates data simulation from a random regression model where the data properties can be controlled by a few input parameters. The data simulation is based on the concept of relevant latent components and relevant predictors, and was developed for the purpose of testing methods for variable selection for prediction. Included are also functions for designing computer experiments in order to investigate the effects of the data properties on the performance of the tested methods. The design is constructed using the Multi-level Binary Replacement (MBR) design approach which makes it possible to set up fractional designs for multi-factor problems with potentially many levels for each factor.
| Version: | 1.0-1 |
| Depends: | FrF2, sfsmisc |
| Suggests: | pls |
| Published: | 2014-11-29 |
| Author: | Solve Sæbø |
| Maintainer: | Solve Sæbø <solve.sabo at nmbu.no> |
| License: | GPL-2 |
| NeedsCompilation: | no |
| In views: | ExperimentalDesign |
| CRAN checks: | simrel results |
| Reference manual: | simrel.pdf |
| Package source: | simrel_1.0-1.tar.gz |
| Windows binaries: | r-devel: simrel_1.0-1.zip, r-release: simrel_1.0-1.zip, r-oldrel: simrel_1.0-1.zip |
| OS X binaries: | r-release: simrel_1.0-1.tgz, r-oldrel: simrel_1.0-1.tgz |
Please use the canonical form https://CRAN.R-project.org/package=simrel to link to this page.


Multipurpose Overlay System with options for multi-step "forms"
Modool uses steps to represent each "screen" of the overlay.
If the step array is one,then the overlay will behave as a single overlay.
If the step array is greater than one, the overlay will behave as a multi-step overlay.
There are many configurations, but only "tmpl" is required, for the overlay to work.


This app is just a small app for an individual to keep track of the amount of time spent on different work items that you can define.
Create projects where you can allocate the amount of time that you worked on it to keep track of how much of time you have spent on it.


Syntax:
ldiff list object => result-list
tailp object list => generalized-boolean
Arguments and Values:
list---a list, which might be a dotted list.
object---an object.
result-list---a list.
generalized-boolean---a generalized boolean.
Description:
If object is the same as some tail of list, tailp returns true; otherwise, it returns false.
If object is the same as some tail of list, ldiff returns a fresh list of the elements of list that precede object in the list structure of list; otherwise, it returns a copy[2] of list.
Examples:
(let ((lists '#((a b c) (a b c . d)))) (dotimes (i (length lists)) () (let ((list (aref lists i))) (format t "~2&list=~S ~21T(tailp object list)~ ~44T(ldiff list object)~%" list) (let ((objects (vector list (cddr list) (copy-list (cddr list)) '(f g h) '() 'd 'x))) (dotimes (j (length objects)) () (let ((object (aref objects j))) (format t "~& object=~S ~21T~S ~44T~S" object (tailp object list) (ldiff list object)))))))) >> >> list=(A B C) (tailp object list) (ldiff list object) >> object=(A B C) T NIL >> object=(C) T (A B) >> object=(C) NIL (A B C) >> object=(F G H) NIL (A B C) >> object=NIL T (A B C) >> object=D NIL (A B C) >> object=X NIL (A B C) >> >> list=(A B C . D) (tailp object list) (ldiff list object) >> object=(A B C . D) T NIL >> object=(C . D) T (A B) >> object=(C . D) NIL (A B C . D) >> object=(F G H) NIL (A B C . D) >> object=NIL NIL (A B C . D) >> object=D T (A B C) >> object=X NIL (A B C . D) => NIL
Side Effects:
Neither ldiff nor tailp modifies either of its arguments.
Affected By: None.
Exceptional Situations:
Should be prepared to signal an error of type type-error if list is not a proper list or a dotted list.
See Also:
Notes:
If the list is a circular list, tailp will reliably yield a value only if the given object is in fact a tail of list. Otherwise, the consequences are unspecified: a given implementation which detects the circularity must return false, but since an implementation is not obliged to detect such a situation, tailp might just loop indefinitely without returning in that case.
tailp could be defined as follows:
(defun tailp (object list) (do ((list list (cdr list))) ((atom list) (eql list object)) (if (eql object list) (return t))))
and ldiff could be defined by:
(defun ldiff (list object) (do ((list list (cdr list)) (r '() (cons (car list) r))) ((atom list) (if (eql list object) (nreverse r) (nreconc r list))) (when (eql object list) (return (nreverse r)))))


Downloads
New Release - JXTA 2.5
Announcements
About the JXTA Community
Board of Directors
JXTA Elections
News and Press
Company Spotlights
Developer Spotlights
Awards
Mailing lists
Discussion Forums
Using JXTA
JXTA FAQ
JXTA Wiki
Programmer's Guide
License
JXTA bindings
Java SE
C/C++/C#
Java ME
JXTA Specification
Contribute


本页所收集的标准仅为网站兼容性相关的 W3C 标准，点击
这里 查看全部 W3C 标准。
The standards listed here are collected particularly for the solution of compatibility issues.
For more
W3C standards, please visit
W3C website.
| 2009-12-22 | Server-Sent Events |
Last Call
Review ended: 2010-06-30 |
| 2009-10-29 | HTTP Vocabulary in RDF 1.0 | Working Draft |
| 2009-10-29 | Representing Content in RDF 1.0 | Working Draft |
| 2008-10-14 | RDFa in XHTML: Syntax and Processing | Recommendation |
| 2008-07-29 | XHTML™ Basic 1.1 | Recommendation |
| 2006-09-20 | XHTML-Print | Recommendation |
| 2003-01-09 | Document Object Model (DOM) Level 2 HTML Specification | Recommendation |
| 2002-08-01 | XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition) | Recommendation |
| 2001-05-31 | XHTML™ 1.1 - Module-based XHTML | Recommendation |
| 2001-05-31 | Ruby Annotation | Recommendation |
| 1999-12-24 | HTML 4.01 Specification | Recommendation |
| 1997-01-14 | HTML 3.2 Reference Specification | Recommendation |
| 2009-01-16 | XHTML Media Types - Second Edition | Group Note |
| 2008-10-14 | RDFa Primer | Group Note |
| 2008-05-30 | Offline Web Applications | Group Note |
| 2002-09-02 | XHTML 1.0 in XML Schema | Group Note |
| 2002-01-31 | XHTML+SMIL Profile | Group Note |
| 2008-04-11 | Cascading Style Sheets (CSS1) Level 1 Specification | Recommendation |
| 2000-11-13 | Document Object Model (DOM) Level 2 Style Specification | Recommendation |
| 1999-06-29 | Associating Style Sheets with XML documents | Recommendation |
| 2009-06-04 | Requirements for Japanese Text Layout | Group Note |
| 2000-11-06 | CSS Techniques for Web Content Accessibility Guidelines 1.0 | Group Note |
| 1998-12-10 | List of suggested extensions to CSS | Group Note |
| 2009-12-22 | Server-Sent Events |
Last Call
Review ended: 2010-06-30 |
| 2009-09-08 | Document Object Model (DOM) Level 3 Events Specification | Working Draft |
| 2003-10-14 | XML Events | Recommendation |
| 2000-11-13 | Document Object Model (DOM) Level 2 Events Specification | Recommendation |
| 2006-02-02 | Remote Events for XML (REX) Requirements | Group Note |
| 2009-09-08 | Document Object Model (DOM) Level 3 Events Specification | Working Draft |
| 2008-05-21 | Progress Events 1.0 | Working Draft |
| 2007-02-16 | XML Events 2 | Working Draft |
| 2006-10-13 | Media Access Events | Working Draft |
| 2008-12-22 | Element Traversal Specification | Recommendation |
| 2009-10-15 | Device APIs Requirements | Group Note |
| 2008-05-30 | Offline Web Applications | Group Note |


proteinFinder module¶
-
class
proteinFinder.
NCBI
(queryLst, db)[source]¶ Bases:
object
Object handling ncbi API
-
queryLst
¶ List with query strings the database should be searched for.
- Type
list of str
-
db
¶ Name of the database, that should be searched in. Full list of options under: https://www.ncbi.nlm.nih.gov/books/NBK25497/table/chapter2.T._entrez_unique_identifiers_ui/?report=objectonly
- Type
-
getNcbiIdFromResponse
(resLst, queryLst)[source]¶ process json server response / get the matching ids for the query
- Parameters
resLst (list of response objects) – List of response objects retrieved from the NCBI server.
queryLst (list of str:) – List with query strings the database was searched by.
- Returns
idsDic – KEY: Query string, VALUE: List of IDs from response.
- Return type
-
queryNcbiDb
(queryLst, db='protein', outFormat='json')[source]¶ Querys list of strings in NCBI database
Makes http GET request to Query NCBI Entrez Programming Utilities (E-utilities) and retrieves response. Only 10 querys per second allowed.
- Parameters
- Returns
resLst – List of response objects retrieved from the NCBI server by the GET() call.
- Return type
list of response objects
-
-
class
proteinFinder.
Uniprot
[source]¶ Bases:
object
-
mapRetrieveUniprot
(ids2map, source_fmt='ACC+ID', target_fmt='ACC', output_fmt='tab', colNames='id, entry name, organism')[source]¶ Calls Uniprot API to map (translate) IDs from or to Uniprot database and retrieve entries after mapping.
Makes a POST request with a list of IDs to Uniprot API. The API can map foreign IDs to Uniprot Accession numbers or Uniprot Accession numbers to foreign IDs. Also after mapping, Uniprot searches the results, it responses with the results in a desired output format.
- Parameters
ids2map (list of strings) – List of ID strings that should be mapped
sourceFmt (string) – Database identifier of uniprot, from which the ID is from (List of identifiers: https://www.uniprot.org/help/api_idmapping)
targetFmt (string) – Database identifier of uniprot, to which the ID should mapped
outputFmt (string) – Desired output format from Uniprot API (List of possible formats https://www.uniprot.org/help/api_queries)
colNames (string) – Optional. Only used when outputFmt is ‘tab’ or ‘xls’. Comma seperated list of column names to retrieve from entry (List of possible columns: https://www.uniprot.org/help/uniprotkb_column_names)
- Returns
response.text – Response body of POST request.
- Return type
JSON as str
-
matchQueryWithResponse
(queryDf, responseDf, idLabel)[source]¶ Outer join with query and response dataframe
- Parameters
queryDf (pandas data frame) – Stores query terms aswell as the matching IDs, retrieved from database search.
responseDf (pandas data frame) – Stores response data from the server.
idLabel (string) – Label for the IDs retrieved. Is used as primary key.
- Returns
allProtInfoDf – Stores query terms and response information.
- Return type
pandas data frame
-
processUniprotRes
(resBody, queryDf, outPath, idLabel)[source]¶ Creates data frame out of Uniprot POST Request
- Parameters
resBody (JSON as str) – Response body from GET() request of uniprot.
queryDf (pandas data frame) – Stores query terms aswell as the matching IDs, retrieved from database search.
outPath (str) – Path to output file.
idLabel (string) – Label for the IDs retrieved. Is used as primary key.
- Returns
protInfoDf – Stores query terms and response information.
- Return type
pandas data frame
-
queryTerms
(queryLst, organismID, outputFormat='list', sort='score', idLabel='ID_Uniprot')[source]¶ Search Uniprot database based on search terms
- Parameters
queryLst (list of str:) – List with query strings the database was searched by.
organismID (str) – Limit the search results to this organism.
outputFormat (str) – Type of format from the server. All choices under, https://www.uniprot.org/help/api_queries .
sort (str) – Determines how the results should be sorted.
idLabel (str) – Label for the IDs retrieved. Is later used as primary key.
- Returns
idDf – Contains information about query term and retrieved id.
- Return type
pandas data frame
-
-
proteinFinder.
readQueryFile
(srcFile, noheaders=False)[source]¶ Read query strings from .csv file
- Parameters
srcFile (string) – Path to .csv file with query strings in first column.
noheaders (boolean) – If true, first row of csv file will be skipped.
- Returns
queryLst – List of query strings the databse should be searched for.
- Return type
list[string]


is designed to provide plugin architecture for java web application development
push by country, push by city.
Click here for demo


>>> from tutil.functional import * >>> go([1, 2, 3, 4], map(lambda v: v + 1), sum) 14
https://github.com/tuyy/tutil
copyright: (c) 2020 tuyy license: MIT, see LICENSE for more details.


This document describes usage of the API provided by the Lookup Library. In this document we assume that someone has already provided us with a lookup implementation (for those seeking how to write a lookup implementation please check the SPI document).
public static Lookup getDefault()The object returned from this method is a global lookup that can serve as a central place for registering services. The default implementation is a lookup that implements the JDK JAR services mechanism and delegates to META-INF/services/name.of.Class files.
If you want to add your class to this lookup just create a file in your
jar file under the META-INF
directory (e.g. META-INF/services/com.my.APIClass)
and let the file contain only one line of text
com.foo.impl.ImplOfTheAPI
(This is more easily done using the @ServiceProvider
annotation.)
com.foo.impl.ImplOfTheAPI
:
import org.openide.util.Lookup; return Lookup.getDefault().lookup(com.my.APIClass.class);
Note: If you use Lookup.Template, the object returned from the lookup is not the object you are looking for but rather a result object (Lookup.Result). You can call methods on such a result object to get the actual results.
Let's examine following example:
import org.openide.util.Lookup; Lookup lookup = ...; Lookup.Template template = new Lookup.Template(MyService.class); Lookup.Result result = lookup.lookup(template); Collection c = result.allInstances(); for (Iterator i = c.iterator(); i.hasNext(); ) { MyService s = (MyService)i.next(); s.callMyService(); }In this example the call to method lookup(...) returns immediately because the result object can be constructed even without real results. The first time you ask for the result object by calling r.allInstances(), the lookup has to supply you the real results and this method can block until the required data are really available.
If you are not interested in all objects as in the previous example, you can use the template to ask for one resulting object (wrapped in special Item instance):
import org.openide.util.Lookup; Lookup lookup = ...; Lookup.Template template = new Lookup.Template(MyService.class); Lookup.Item item = lookup.lookupItem(template); MyService s = (MyService)item.getInstance(); s.callMyService();Again, the Item object can construct the real instance only if you call getInstance. The item can be useful even without calling getInstance - you can get its display name or an unique id. You can use this information, for example, for constructing menu items without the need to instantiate (or even load!) the class implementing the functionality. Only when the real functionality is needed (e.g. the user has selected the menu item) you can call getInstance and call the real meat of the implementation.
So here is some sample code using the listenner:
import org.openide.util.Lookup; import org.openide.util.LookupListener; import org.openide.util.LookupEvent; Lookup lookup = ...; Lookup.Template template = new Lookup.Template(MyService.class); final Lookup.Result result = lookup.lookup(template); result.addLookupListener(new LookupListener() { public void resultChanged(LookupEvent e) { reaction(result); } }); reaction(result); } private static void reaction(Lookup.Result r) { for (Iterator i = r.allInstances().iterator(); i.hasNext(); ) { MyService s = (MyService)i.next(); s.callMyService(); } }Please note that we first attach a listener and then call the reaction method. This ensures that we always get the newest possible state. Also you must be careful in the reaction method since it can be called from two different threads simultaneously (your code has to be prepared for this).


If you want to shut down the instance instead of releasing (deleting) the instance when the idle timeout expires, you can select this option.
Note: When you shut down the instance, only the basic resources of the elastic cloud server (including vCPU, memory, and mirroring) will stop billing,
while the cloud hard disk (system disk, data disk) and elastic public network IP will still be billed on demand.


It would take me so long to find different resources, this website made it much easier for me!
- Robert Pattinson
This website has given me a variety of ways to learn, i highly recommend it.
- Jennifer Lawrence
I find this website incredibly easy to use and it has made it easy for me to learn how to code!
- Ryan Gosling
❮
❯


| DOSE: |
20 mg |
smoked |
5-MeO-DMT |
(powder / crystals) |
Well, let me start off by saying that I would consider myself to be a very experienced drug user, but nothing could have prepared me for the effects of 5-meo-dmt. I thought myself to be jaded to the effects of drugs, but this stuff knocked me on my ass!!!
My friend had just purchased a large quantity of 5-meo-dmt. I walked into his house with my boyfriend and my friend had already experienced the drug (by himself I might add...the crazy bastard!). I was very excitied to try this drug, after hearing about his experience.
I laid down on his bed and he held a small glass pipe to my mouth, with a flame underneath the bowl. I inhaled the substance and then began to cough profusely. My boyfriend was on the other side of the room, laying on a couch, and he also took a hit of it and laid back. I laid there and everything began to look fuzzy. I was waiting for the full effects to begin.
I sat up and commented on how everything looked weird and fuzzy. My boyfriend was experiencing the same thing. My friend said, 'you guys don't feel it yet?!?' I told him I was waiting for it to come on and he said I should feel it immediately.
I took another hit and again began to cough profusely. I definitely felt the effects this time. I went to grab a bottle of coke to get the soreness out of my throat, and it was very difficult to drink.
I laid back and felt like I had just done 50 whippets. The room was going wild and I could not focus or concentrate on anything. Breathing became very difficult because of the harshness of the smoke. I had no real concept of what was going on. I could not fathom reality, time, where I was, or what the hell was going on. I described this feeling to a friend as being in a k hole, on numerous hits of acid, while doing whippets.
I became extremely paranoid as breathing seemed to become increasingly difficult. I began to try to take deep breaths, but I didn't know if the air was coming in or going on. I really thought that I was going to die.  I pulled all my strength together and yelled 'HELP!' It felt like I was having a nightmare and trying to scream.
I realized I was screaming 'HELP! HELP!' and all I wanted to do was go to the hospital. I was thinking about my life and the consequences of going to the hospital, but all of that seemed unimportant because I thought I was really dying. I could not see straight at all and I didn't know what was going on around me. I began to try to rip my hair out. I was terrified out of my mind. I had no idea that my boyfriend (also on 5-meo-dmt) had snapped out of his trip and was on top of me, trying to restrain me. I remember pulling on my hair and my forehead feeling sweaty. I don't really know anything else that was going on around me.
The next thing I knew, I was in the fetal position and I opened my eyes to see my friend standing in the room and my boyfriend sitting on the couch. Everything looked very cloudy and I was seeing crazy trails off of everything. I still could not see straight, but at this point, I had a grip on what was going on. My friend ask if I was ok and I said that I wasn't sure.
I slowly got up and asked my boyfriend to come and sit with me. I was holding onto him and my friend left the room. I began to touch my boyfriend and I felt highly sensual (not sexual). I wanted to touch him all over, but he was still feeling somewhat of the after effects himself, although he had experienced nothing close to what I had.
After everything looked more and more normal, I began asking what had happened, where everyone was while I was freaking out, and what I was doing. I felt a sense of relief and all the tension and anxiety I had felt seemed to melt away.
I watched another person try 5-meo-dmt that night and he just laid there, breathing heavily, with a big smile on his face. I don't know why I reacted the way I did and nobody else had.
I have never flipped out on drugs before or felt a drug take over me the way 5-meo-dmt had. I continue to ponder the effect it had on me and I think I may try it again, in a safe, controlled enviroment, but not anytime soon.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


This function computes the t-test on the inputs R times and samples the pooled data (i.e. x and y together) without replacement. The function calculates the p-value by
permutation_test(x, y, R, use_sample = TRUE, ...)
| x | a numeric vector |
|---|---|
| y | a numeric vector |
| R | number of resamples. Must be between 99 and 999. |
| use_sample | logical. Use the sample() function? If FALSE, this function will use the runif() function to draw random samples. |
| ... | optional (named) parameters
|
List containing
data: list containing input parameters
results: result of the permutation test. Contains indices for each run, p-values, options passed to the t-tests
Rizzo, Maria L. "Statistical Computing with R". Chapman and Hall/CRC, 2007. pp. 183-188


Hawaiian
Ham and Pineapple for some reason.
Click to Email us your query!
Click to give us a call!
Back to Home


Readmos library
Your project name
This is a little description of your project.
Open project
Your project 2 name
This is a little description of your project 2.
Open project


Aakash E-VACCINATION
Home
Vaccination
AAKASH
DAS
System Engineer at TCS Digital | 5⭐ at Hackerrank | Competitive Coder
Durgapur, West Bengal - 713213
<EMAIL_ADDRESS>+91-94349 51110
SOCIAL
@aakash
@iamad99
@agendaxd276
VACCINATION BOOKING
District
Pincodes
Age
18+
45+
Dose
1
st
2
nd
Vaccine
Any
Covishield
Covaxin
Sputnik V
Fees
Free
Paid
Any
Date
Login
OTP
Logged In
session expiring soon
Beneficiaries
No name found
Fetch Available Slots
Fetching Slots
Captcha


Daikin 1.5 Ton 3 Star Inverter Split AC (Copper, PM 2.5 Filter,2020 Model, MTKL50TV, White)
Price-Rupees 50,000
Samsung 6.5 kg Fully-Automatic Top Loading Washing Machine (WA65A4002VS/TL, Imperial Silver, Center Jet Technology)
Price-Rupees 17,000
Galaxy note 20 ultra
New Note 20 Ultra 256GB-Black
Price-Rupees 1,04,999
Galaxy S21 Ultra
New S21 Ultra 5G 128GB-Black


ANBESOL JR- benzocaine gel
ANBESOL REGULAR STRENGTH- benzocaine gel
ANBESOL REGULAR STRENGTH- benzocaine solution
ANBESOL MAXIMUM STRENGTH- benzocaine gel
ANBESOL MAXIMUM STRENGTH- benzocaine solution
Pfizer Consumer Healthcare
Disclaimer: Most OTC drugs are not reviewed and approved by FDA, however they may be marketed if they comply with applicable regulations and policies. FDA has not evaluated whether this product complies.
ACTIVE INGREDIENT
Anbesol Regular Strength Liquid and Gel
Benzocaine 10%
Anbesol Jr. Gel
Benzocaine 10%
Anbesol Maximum Strength Liquid and Gel
Benzocaine 20%
USES
- temporarily relieves pain associated with the following mouth and gum irritations:
- toothache
- sore gums
- canker sores
- braces
- minor dental procedures
- dentures
WARNINGS
Allergy alert
Do not use this product if you have a history of allergy to local anesthetics such as procaine, butacaine, benzocaine, or other "caine" anesthetics
When using this product
- avoid contact with the eyes
- do not exceed recommended dosage
- do not use for more than 7 days unless directed by a doctor/dentist
Stop use and ask a doctor if
- sore mouth symptoms do not improve in 7 days
- irritation, pain, or redness persists or worsens
- swelling, rash, or fever develops
Keep out of reach of children.
If more than used for pain is accidentally swallowed, get medical help or contact a Poison Control Center right away.
DIRECTIONS
Anbesol Regular and Maximum Strength Liquid
- adults and children 2 years of age and older:
- wipe liquid on with cotton, or cotton swab, or fingertip
- apply to the affected area up to 4 times daily or as directed by a doctor/dentist
- children under 12 years of age: adult supervision should be given in the use of this product
- children under 2 years of age: consult a doctor/dentist
Anbesol Regular and Maximum Strength Gel
- to open tube, cut tip of the tube on score mark with scissors
- adults and children 2 years of age and older: apply to the affected area up to 4 times daily or as directed by a doctor/dentist
- children under 12 years of age: adult supervision should be given in the use of this product
- children under 2 years of age: consult a doctor/dentist
- for denture irritation:
- apply thin layer to the affected area
- do not reinsert dental work until irritation/pain is relieved
- rinse mouth well before reinserting
Anbesol Jr. Gel
- to open tube, cut tip of the tube on score mark with scissors
- adults and children 2 years of age and older: apply to the affected area up to 4 times daily or as directed by a doctor/dentist
- children under 12 years of age: adult supervision should be given in the use of this product
- children under 2 years of age: consult a doctor/dentist
OTHER INFORMATION
Anbesol Regular Strength Liquid and Gel, Anbesol Maximum Strength Liquid, and Anbesol Jr. Gel
Store at 20-25°C (68-77°F)
Anbesol Maximum Strength Gel
Store at 20-25°C (68-77°F). Do not refrigerate.
INACTIVE INGREDIENTS
Anbesol Regular Strength Liquid
benzyl alcohol, D&C red no. 33, D&C yellow no. 10, FD&C blue no. 1, FD&C yellow no. 6, flavor, methylparaben, polyethylene glycol, propylene glycol, saccharin
Anbesol Regular Strength Gel
benzyl alcohol, carbomer 934P, D&C red no. 33, D&C yellow no. 10, FD&C blue no. 1, FD&C yellow no. 6, flavor, glycerin, methylparaben, polyethylene glycol, propylene glycol, saccharin
Anbesol Jr. Gel
artificial flavor, benzyl alcohol, carbomer 934P, D&C red no. 33, glycerin, methylparaben, polyethylene glycol, potassium acesulfame
Anbesol Maximum Strength Liquid
benzyl alcohol, D&C yellow no. 10, FD&C blue no. 1, FD&C red no. 40, flavor, methylparaben, polyethylene glycol, propylene glycol, saccharin
Anbesol Maximum Strength Gel
benzyl alcohol, carbomer 934P, D&C yellow no. 10, FD&C blue no. 1, FD&C red no. 40, flavor, glycerin, methylparaben, polyethylene glycol, propylene glycol, saccharin
PRODUCT PACKAGING
The product packaging shown below represents a sample of that currently in use. Additional packaging may also be available.
PRINCIPAL DISPLAY PANEL - Anbesol Jr. Gel
bubble
gum
FLAVOR
gel
Anbesol
JR.®
For kids
& teens
Oral Anesthetic/
Benzocaine 10%
DOCTOR
RECOMMENDED
Instant
Brace Pain Relief
- ✓
- Brace Pain
- ✓
- Gum Pain
- ✓
- Canker Sores
- ✓
- Toothaches
NET WT 0.33 OZ (9 g)
Safety Sealed Tube:
Do Not Use if tube tip is cut prior to opening.
PRINCIPAL DISPLAY PANEL - Anbesol Regular Strength Gel
cool mint
gel
Anbesol®
Oral Anesthetic/Benzocaine 10%
REGULAR
STRENGTH
DOCTOR
RECOMMENDED
Instant
Pain Relief
- ✓
- Toothaches
- ✓
- Gum Pain
- ✓
- Canker Sores
- ✓
- Denture Pain
NET WT 0.33 OZ (9 g)
Safety Sealed Tube:
Do Not Use if tube tip is cut prior to opening.
PRINCIPAL DISPLAY PANEL - Anbesol Regular Strength Liquid
cool mint
liquid
Anbesol®
Oral Anesthetic/Benzocaine 10%
REGULAR
STRENGTH
DOCTOR
RECOMMENDED
Instant
Pain Relief
- ✓
- Toothaches
- ✓
- Gum Pain
- ✓
- Canker Sores
- ✓
- Denture Pain
NET WT 0.41 FL OZ (12 ml)
Do Not Use if plastic blister or backing material is broken
or if backing material is separated from the plastic.
PRINCIPAL DISPLAY PANEL - Anbesol Maximum Strength Gel
gel
Anbesol®
Oral Anesthetic/Benzocaine 20%
MAXIMUM
STRENGTH
DOCTOR
RECOMMENDED
Instant
Pain Relief
- ✓
- Toothaches
- ✓
- Gum Pain
- ✓
- Canker Sores
- ✓
- Denture Pain
NET WT 0.33 OZ (9 g)
Safety Sealed Tube:
Do Not Use if tube tip is cut prior to opening.
PRINCIPAL DISPLAY PANEL - Anbesol Maximum Strength Liquid
liquid
Anbesol®
Oral Anesthetic/Benzocaine 20%
MAXIMUM
STRENGTH
DOCTOR
RECOMMENDED
Instant
Pain Relief
- ✓
- Toothaches
- ✓
- Gum Pain
- ✓
- Canker Sores
- ✓
- Denture Pain
NET WT 0.41 FL OZ (12 ml)
Do Not Use if plastic blister or backing material is broken
or if backing material is separated from the plastic.


Year 2017
Strategic Innovation, Growth & Productivity.
How we execute in 2017?
Asset Utilization & Return on Assets.
Return On Investment.
Asset Utilization & Return On Assets
Return on Investment.
What am I not afraid of?
- Failures - When the intentions are good.
- Changes
- Are constant.
- Business thrives on changes.
- Develops agility during changes.
- Challenges establishment thoughts and revolutionize Innovation.
- What others think? Not thin skinned.
- Being extraordinarily audacious
- Perception - Not running for higher office.

What I do have is ...
Passion for ...
- Doing right thing at right time.
- Revolutionary & extraordinary changes.
- Change that can create history.
- Define destiny rather than being shaped by it.
- Quality and Simplicity
- Greater cause than being selffish.