Search

This deliverable D13.3 - "Software Release Final Activity Report - JRA2" documents the software packages produced by the project to implement the functionalities of the ARIADNEplus infrastructure, accessible from https://ariadne.d4science.org. These open- source software releases followed the procedures described in D13.1 Software Release Procedures and Tools - JRA2 governing the release of software, methods, and tools for the ARIADNEplus infrastructure. D13.3 reports on (i) the ARIADNE VRE software releases, where a total of 29 different release cycles were performed during the project period. Each release contained EUPL licensed software, whose source is accessible on the Code Versioning System (CVS) platform publicly available online at https://code-repo.d4science.org/gCubeCI/gCubeReleases, and reports on (ii) the ARIADNE Portal software releases whose source is accessible on the Code Versioning System (CVS) platform publicly available online https://github.com/ARIADNE- Infrastructure/portal. These activities have been carried out in the context of Task 13.4 Software integration and release (JRA2.4) as part of Work Package 13 (WP13). This task managed the process of software maintenance, enhancement, and provisioning in JRA work packages. Thus, it i) defines the release and provisioning procedures; ii) establishes the release plan; iii) coordinates the release process; iv) operates the tools required to support the release and provisioning activities; v) validates the software documentation; vi) takes care of the distribution of the software and its provisioning. This task benefits from the practices established and experience gained within the D4Science infrastructure.

Virtual Research Environments (VREs) are "systems" specifically conceived to provide their users with a web-based set of facilities (including services, data and computational facilities) to accomplish a set of tasks by dynamically relying on the underlying infrastructure. VREs are among the key products developed and delivered by the ARIADNEplus project to support the target communities and application scenarios in archaeology. The development of VREs is based on three main activities: (i) the development of software artifacts that realise a set of functions (including those needed for accessing certain datasets), (ii) the deployment of these artifacts in an operational infrastructure following the release procedures and tools presented in the deliverable D13.1 "Software Release Procedures and Tools JRA2", and (iii) the final deployment and operation of well-defined Virtual Research Environments by exploiting the facilities offered by the underlying D4Science infrastructure and its services [1]. This deliverable D13.4 - "VREs Operation Final Activity Report'' is the updated version of D13.2 - "VREs Operation Mid-term Activity Report ''. D13.4 documents the last of the above- mentioned three activities - i.e. the exploitation of the services and technologies offered by the underlying infrastructure to serve the needs of defined scenarios - as implemented in the second period, from January 2021 to November 2022 - of the ARIADNEplus project. Specifically, it focuses on how the components have been exploited and operated to support the development of the ARIADNEplus VRE gateway https://ariadne.d4science.org, its underlying infrastructure, and the VREs from M25 (January 2021) to M47 (November 2022). These activities have been carried out within Work Package 13. Specifically in Task 13.1 Infrastructure Operation (JRA2.1) and Task 13.3 VREs Operation (JRA2.3). In addition to the 5 VREs created and operated in the first period, 3 more VREs were created and operated in the second reporting period, for a total of 8 VREs. One VRE of the second reporting period, namely ARIADNEplus Lab (cf. Section 4.6), was created in July 2021 as the virtual laboratory to support developers, researchers, data managers, and data analysts belonging to the archaeological community worldwide. The "Geoportale Nazionale per l'Archeologia (GNA)" VRE (cf. Section 4.7) was created in January 2022, as the evolution of the existing Geoportal Prototype VRE (cf. Section 4.4), which was developed for the integration, validation, harmonization, visualization, and access of archaeological georeferenced datasets collected in Italy. Finally, the Esquiline VRE (cf. Section 4.8) was created in October 2022 for the integration and display of data originating from 19th century excavations and historical cartography in a spatio-temporal database, allowing the reconstruction of the transformation of an urban landscape through the centuries. As of November 2022, the VREs are serving the needs of more than 400 users in total spread across 21 countries and more than 10.000 user sessions. This required to deal with approximately 100 tickets (59 requests for support, 9 requests for incidents and bugs, 9 requests for Virtual Machine or Container creations).

InfraScience is a research group of the National Research Council of Italy - Institute of Information Science and Technologies (CNR - ISTI) based in Pisa, Italy. This report documents the research activity performed by this group in 2021 to highlight the major results. In particular, the InfraScience group confronted with research challenges characterising Data Infrastructures, eScience, and Intelligent Systems. The group activity is pursued by closely connecting research and development and by promoting and supporting open science. In fact, the group is leading the development of two large scale infrastructures for Open Science, i.e. D4Science and OpenAIRE. During 2021 InfraScience members contributed to the publishing of 25 papers, to the research and development activities of 18 research projects (15 funded by EU), to the organization of conferences and training events, to several working groups and task forces.

D4Science is an IT infrastructure specifically conceived to support the development and operation of Virtual Research Environments by the as-a-Service provisioning mode. This report documents the activities performed in 2022 to develop this infrastructure and support several projects and exploitations.

InfraScience is a research group of the National Research Council of Italy - Institute of Information Science and Technologies (CNR - ISTI) based in Pisa, Italy. This report documents the research activity performed by this group in 2022 to highlight the major results. In particular, the InfraScience group confronted with research challenges characterising Data Infrastructures, e-Science, and Intelligent Systems. The group activity is pursued by closely connecting research and development and by promoting and supporting open science. In fact, the group is leading the development of two large scale infrastructures for Open Science, i.e. D4Science and OpenAIRE. During 2022 InfraScience members contributed to the publishing of several papers, to the research and development activities of 18 research projects (15 funded by EU), to the organization of conferences and training events, to several working groups and task forces.

This deliverable D13.2 - "VREs Operation Mid-term Activity Report" describes the activities carried out during the first 24 months of the ARIADNEplus project within Work Package 13. Specifically, in Task 13.1 Infrastructure Operation (JRA2.1) and Task 13.3 VREs Operation (JRA2.3). It reports the procedures governing the operation of the VREs as well as the status of the aggregated resources at mid-term in the ARIADNEplus infrastructure.

The enhancements in IT solutions and the open science movement are injecting changes in the practices dealing with data collection, collation, processing and analytics, and publishing in all the domains, including agri-food. However, in implementing these changes one of the major issues faced by the agri-food researchers is the fragmentation of the “assets” to be exploited when performing research tasks, e.g. data of interest are heterogeneous and scattered across several repositories, the tools modellers rely on are diverse and often make use of limited computing capacity, the publishing practices are various and rarely aim at making available the “whole story” with datasets, processes, workflows. This paper presents the AGINFRA PLUS endeavour to overcome these limitations by providing researchers in three designated communities with Virtual Research Environments facilitating the use of the “assets” of interest and promote collaboration.

The enhancements in IT solutions and the open science movement are injecting changes in the practices dealing with data collection, collation, processing, analytics, and publishing in all the domains, including agri-food. However, in implementing these changes one of the major issues faced by the agri-food researchers is the fragmentation of the “assets” to be exploited when performing research tasks, for example, data of interest are heterogeneous and scattered across several repositories, the tools modelers rely on are diverse and often make use of limited computing capacity, the publishing practices are various and rarely aim at making available the “whole story” including datasets, processes, and results. This paper presents the AGINFRA PLUS endeavor to overcome these limitations by providing researchers in three designated communities with Virtual Research Environments facilitating the use of the “assets” of interest and promote collaboration. © 2020 John Wiley & Sons Ltd

This deliverable D5.2 "Virtual Research Environment Operation Report years 1-2" describes the activities carried out during the first 24 months of the DESIRA project within Work Package 5. Specifically in Task 5.1 "Knowledge Infrastructure: the DESIRA Virtual Research Environment" and Task 5.2 "Integration of Services and Tools, and Use Reporting". It reports the procedures governing the operation of the VREs as well as the status of the aggregated resources at mid-term in the DESIRA infrastructure. Virtual Research Environments (VREs) are "systems" specifically conceived to provide their users with a web-based set of facilities (including services, data and computational facilities) to accomplish a set of tasks by dynamically relying on the underlying infrastructure. VREs are among the key products to be developed and delivered by the DESIRA project to support Project coordination, Living Labs activities and Rural Digitization Forums activities. The development of VREs is based on three main activities: (i) the development of software artefacts that realise a set of functions (including those needed for accessing specific datasets), (ii) the deployment of these artefacts in an operational infrastructure following the release procedures and tools, and (iii) the final deployment and operation of well-defined Virtual Research Environments by exploiting the facilities offered by the underlying D4Science infrastructure and its services [1, 2]. This report documents the last of the above three activities - i.e. the exploitation of the services and technologies offered by the underlying infrastructure to serve the needs of defined scenarios - as implemented in the context of the DESIRA project from June 2019 to May 2021. The DESIRA Infrastructure Gateway actually offers end-user access to 14 VREs. As of June 2019, 1 VREs were created and operated. Specifically, the DESIRA Project VRE (cf. Sec 3.1.1) was created before the project kick-off. As of May 2021, these VREs have served the needs of more than 370 users and more than 7.000 user sessions. This required dealing with 177 tickets (103 related to the project management, 28 requests for support and enhancements, five requests for incidents and bugs, 14 requests for VRE creations).

The Blue-Cloud project is piloting a cyber platform bringing together and providing access to multidisciplinary data from observations and models, analytical tools, and computing facilities essential to support research to understand better and manage the many aspects of ocean sustainability. This goal is realised by developing, deploying and operating the Blue-Cloud platform whose architecture consists of two major families of components: (a) the Blue Cloud Data Discovery and Access System to serve federated discovery and access to 'blue data' infrastructures; and (b) the Blue Cloud Virtual Research Environment (VRE) component to provide a Blue Cloud VRE as a federation of computing platforms and analytical services. This Deliverable D4.4 "Blue Cloud VRE Common Facilities (Release 2)" is the revised version of the D4.2 "Blue Cloud VRE Common Facilities (Release 1)". This revised version of the document covers the second period of the project, from M13 up to M27, including the up-to-date information of the services reported on D4.2 and the new services that have been developed and added to the VRE common facilities in the reporting period to serve the needs of the Blue Cloud community. The major changes and new services this deliverable introduces are: an Orchestrator (cf. Sec. 3.3), i.e. a software that allows for a declarative, technology agnostic definition of workflows to coordinate the execution of tasks across diverse services and systems; enhancements to the Workspace service to support tailored storage persistence and satisfy different application scenarios (cf. Sec. 4.1); enhancements in the Publishing Framework (cf. Sec. 6), namely the catalogue extension to deposit catalogue items to Zenodo and the facility to publish geospatial data from the workspace; the facility to interface with the Data Discovery & Access System (cf. Sec. 7.1) to transfer datasets of interest into the workspace for future uses; the notebook to facilitate the exploitation of the WEkEO Harmonised Data Access (HDA) API (cf. Sec. 7.2). This deliverable also updates the Identity and Access Management (cf. Sec. 3.1) and the Analytics Framework (cf. Sec. 5.1 and Sec 5.2) with minor changes reflecting the activities performed in the reporting period. A description of all the services previously documented in D4.2, not modified in the period, is preserved for this document to be self-contained and provide the reader with an overall description of the whole VRE Common Facilities offering. A total of 15 services and components are described in this deliverable by reporting their design principles, architecture and main features. These services and components contribute functionalities to the Blue Cloud VRE Enabling Framework (Identity and Access Management, VRE Management, Orchestrator), Collaborative framework (Workspace and Social Networking), Analytics Framework (Software and Algorithm Importer, Smart Executor), Publishing Framework (Catalogue Service) and improved support for RStudio, JupyterHub, ShinyProxy, and Docker Applications. Additionally, two new VRE services, aiming at bridging two VRE external systems such as the the WEkEO1 catalogue from Copernicus and the Data Discovery and Access from Blue-Cloud with the VRE tools are described. Services and components discussed in this deliverable have contributed to 14 gCube releases, from gCube 4.26 (November 2020) to gCube 5.6.0 (November 2021). They have been used to develop and operate the Virtual Laboratories of the Blue Cloud gateway https://blue-cloud.d4science.org and its underlying infrastructure. At the time of this deliverable the Blue-Cloud gateway and its services are serving more than 730 users with a total of 19000+ working sessions.

InfraScience is a research group of the National Research Council of Italy - Institute of Information Science and Technologies (CNR - ISTI) based in Pisa, Italy. This report documents the research activity performed by this group in 2020 to highlight the major results. In particular, the InfraScience group confronted with research challenges characterising Data Infrastructures, e\-Sci\-ence, and Intelligent Systems. The group activity is pursued by closely connecting research and development and by promoting and supporting open science. In fact, the group is leading the development of two large scale infrastructures for Open Science, \ie D4Science and OpenAIRE. During 2020 InfraScience members contributed to the publishing of 30 papers, to the research and development activities of 12 research projects (11 funded by EU), to the organization of conferences and training events, to several working groups and task forces.

The Blue-Cloud project plans to pilot a cyber platform bringing together and providing access to multidisciplinary data from observations and models, analytical tools, and computing facilities essential to support research to understand better and manage the many aspects of ocean sustainability. To achieve this goal, Blue-Cloud is developing, deploying, and operating the Blue-Cloud platform whose architecture consists of two families of components: (a) the Blue Cloud Data Discovery and Access service component to serve federated discovery and access to 'blue data' infrastructures; and (b) the Blue Cloud Virtual Research Environment (VRE) component to provide a Blue Cloud VRE as a federation of computing platforms and analytical services. This deliverable presents the Blue Cloud Virtual Research Environment constituents by focusing on both new services and revised existing services that have been developed in the reporting period to serve the needs of the Blue Cloud community. In particular, this deliverable describes a total of 11 services and components. These services and components contribute functionalities to the Blue Cloud VRE Enabling Framework (Identity and Access Management, VRE Management), Collaborative framework (Workspace and Social Networking), Analytics Framework (Software and Algorithm Importer, Smart Executor), Publishing Framework (Catalogue Service) and improved support for RStudio, JupyterHub, ShinyProxy, and Docker Applications. The services are described below by reporting their design principles, architectures, and main features. The deliverable also describes the procedures and approaches governing services and components released by highlighting how Gitea (as Git hosting service), Jenkins (as automation server), and Maven (as project management and comprehension tool) are used to guarantee continuous integration processes. Services and components discussed in this deliverable contribute to 11 gCube open-source software system releases (from gCube 4.16 up to gCube 4.25.1) and are in the pipeline for the next ones. They have been used to develop and operate the Virtual Laboratories of the Blue Cloud gateway https://blue-cloud.d4science.org and its underlying infrastructure. At the time of this deliverable (November 2020), the gateway hosts a total of 8 VREs and VLabs, including five specifically conceived to support the co-development of some of the Blue-Cloud demonstrators (namely, the Aquaculture Atlas Generation for Demonstrator #5, the Blue-Cloud Lab for several demonstrators, the GRSF pre for Demonstrator #4, the Marine Environmental Indicators for Demonstrator #3, the Zoo-Phytoplankton EOV for Demonstrator #1). This gateway and its tools serve more than 400 users that (since January 2020) performed a total of more than 5000 working sessions, more than 1700 accesses to the Workspace, and more than 750 analytics tasks. These exploitation and uptake indicators are likely to grow in the coming months thanks to data updates and continued use, further development of existing VLabs, and finally, the creation of new ones.

The DESIRA Virtual Research Environment specification consists of a hardware layer and a service layer. The former is made available by the D4Science Infrastructure 1 [1, 2] and it is organized as a dynamic pool of virtual machines, supporting computation and storage. The operations and management of those resources is performed via a set of enabling technologies selected to ensure availability and reliability of the infrastructure while e guaranteeing reduction of costs of ownership and a set of supporting technologies selected to ensure secure monitoring, alerting and provisioning. The service layer, illustrated in Figure 1, consists of three service frameworks, which can be summarized as a follows: o Enabling Framework: the enabling framework, framework , based on the gCube System [3], includes services required to support the operation of all services and the VREs supported by such services. As such it includes: a resource registry service, to which all e-infrastructure infrastructure resources (data sources, services, computational nodes, etc.) can be dynamically (de)registered and discovered by user and other services; Authentication and Authorization services, as well as Accounting Services, capable of both granting ing and tracking access and usage actions from users; and a VRE manager, capable of deploying in the collaborative framework VREs inclusive of a selected number of "applications", generally intended as sets of interacting services; o Storage Framework: the storage framework includes services for efficient, advanced, and on on-demand management of digital data, encoded as: files in a distributed file system, collection of metadata records, and time series in spatial databases; such services are used by all other services in the architecture, exception made for the enabling framework; o Collaborative framework : the collaborative framework includes all services deployed for the scientists and for each of them provides social networking services, user management services, shared workspace services. In addition, addition it comprises the part on the Web UI access to the Virtual Research Environment.

This deliverable D13.1 - "Software Release Procedures and Tools JRA2" describes the activities carried out during the first six months of the ARIADNEplus project within Task 13.4 (T13.4) Software integration and release (JRA2.4) (Work Package 13 - WP13) and describes the procedures governing the release of software, methods, and tools for the ARIADNEplus infrastructure. This task is in charge of managing the process of the software maintenance, enhancement, and provisioning in JRA work packages. Thus, it i) defines release and provisioning procedures; ii) establishes the release plan; iii) coordinates the release process; iv) operates the tools required to support the release and provisioning activities; v) validates the software documentation; vi) takes care of the distribution of the software and its provisioning. This task benefits from the practices established and experience gained within the D4Science infrastructure. The procedures are documented through a set of documentation pages for single facilities hosted by the gCube wiki. In particular, this report provides the instructions and rules for three main patterns governing the provision of software and tools to the ARIADNEplus infrastructure. The first pattern is related to the provision of software to the gCube infrastructure enabling technology. This pattern describes the procedures for the storage of software and its management; the continuous integration of the software to build releasable software artefacts; and the generation of software distribution packages. The second pattern is related to the provision of software methods elaborated by the ARIADNEplus community requiring execution within the ARIADNEplus infrastructure. The third pattern is instead related to the provisions and integration of tools into the ARIADNEplus infrastructure.

Virtual Research Environments and Virtual Laboratories are among the key products the BlueBRIDGE project is called to develop and to deliver to serve its target communities and application scenarios. The deployment and operation of a Virtual Research Environment is a task that involves the reuse of existing technologies as well as the development of new technologies aiming at offering new facilities. The development of the technology, both the generic as well as that which is oriented to serve the specific needs of a given community/target scenario, is captured by other deliverables. This report describes the activities performed to provide the BlueBRIDGE community with the set of Virtual Research Environments (VREs) and Virtual Laboratories (VLabs) hosted by the BlueBRIDGE portal during the entire duration of the project. A total of 66 VREs / VLabs have been deployed and operated, overall serving more than 3000 users across 32 countries and 124 different organizations. Such VREs / VLabs include "private" ones (66% circa), i.e. environments whose membership is by invitation only, "restricted" ones (15% circa), i.e. environments that users can request to join yet the requests have to be explicitly approved by the managers, and "open" ones (18% circa), i.e. environments that any user can request to join and no approval is needed. The 45% circa of the served users is exploiting "open" environments, the 34% circa is exploiting "private" environments, and the 19% circa is exploiting "restricted" environments. During the project, more than 980 requests for support, incident or bug have been resolved (441 requests for support and 546 requests for incidents and bugs).

This deliverable documents the implementation of the data processing solution defined in D7.1 "Interoperable data processing for environmental RIs projects: system design". The actual deliverable consists of the software realising the envisaged solution and the instances of it made available to the ENVRI community in the large. The distinguishing features of the proposed solution are (a) to be suitable for serving the needs of scientists involved in ENVRI RIs, (b) to be open and extensible both with respect to the algorithms and methods it enables and the computing platforms it relies on to execute those algorithms and methods, (c) to be open-science-friendly, i.e. it is capable of incorporating every algorithm and method integrated into the data processing framework as well as any computation resulting from the exploitation of integrated algorithms into a "research object" catering for citation, reproducibility, repeatability and provenance. The proposed solution is part of a larger software system named gCube and has been provisioned to ENVRI RIs via several Virtual Research Environments operated by D4Science.

Deliverable D3.1 "Open Science Data Analytics Technologies" is a deliverable of type Demonstrator meaning that it manifests in artefacts (software releases) other than reports. In particular, the deliverable is about the software realising the Data Analytics & Processing Layer of the AGINFRA+. This software is part of a large software system named gCube (www.gcube-system.org). The gCube system offers a large array of services supporting the entire lifecycle underlying a research activity (data management and collation, analytics, collaboration, sharing) and the possibility to combine these services in Virtual Research Environments1. In the context of AGINFRA PLUS the following gCube components have been primarily exploited, consolidated and enhanced to serve the analytics needs arising in the context of the project use cases. DataMiner, i.e. a service enacting its users to perform data analytics tasks by relying on an array of analytics methods and a distributed and heterogeneous computing infrastructure. This service is available by a web-based GUI as well as via a web-based API based on the OGC WPS standard. SAI (Statistical Algorithm Importer), i.e. a service enacting its users to make available their own analytics methods via the DataMiner service. In addition to that, the entire analytics solution made available for AGINFRA PLUS cases counts on (i) a shared workspace realising a cloud-based file manager for managing content of interest and sharing this content with co-workers, (ii) a social networking area enabling users to post messages and have discussions, (iii) a flexible catalogue enabling to publish and discover items of interest including "research objects" resulting from an analytics task. This technology is deployed in its latest version in every Virtual Research Environment supporting AGINFRA PLUS cases2. The major enhancements to the technology pertaining to AGINFRA PLUS have been included in three gCube major releases3 4.7 (October 2017), 4.8 (November 2017), and 4.9 (under production).In particular, with these releases a new"black-box" oriented approach (https://wiki.gcubesystem. org/gcube/Statistical_Algorithms_Importer:_Java_Project#Black_Box_Integration)has been envisaged and implemented to enact analytics method owners and developers to easily integrate theirsolutions into the DataMinerservice. Among the supported black-box typologies there is that for KNIME workflows, i.e. analytics methods implemented by a KNIME workflow. KNIME is among the key technologies supporting the Food Safety Risk Assessment cases. In order to enact the execution of KNIME-based black-boxes, the distributed computing part of the data analytics platform has been extended to integrate the KNIME execution engine. Other cases are counting on the same mechanism to integrate entire applications (WOFOST4) as well as Python-based methods.

Unlike English and Dutch, German does not allow a genitive to follow a universal quantifier: (i) All John’s friends... (ii) Al Jans vrienden... (Dutch) (iii) *All(e) Johanns Freunde... (German) In this article I show that this discrepancy results from two facts. Firstly, the German Saxon Genitive is a true case ending assigned in [Spec, NP] or [Spec, PossP] while in Dutch and English genitive case cannot be assigned at the N or n level (without a preposition) and the Saxon Genitive is more like a possessive adjective, initiating as the head of PossP and terminating in D. Secondly, in Germanic, D or [Spec, DP] must be overtly occupied in case of definiteness, and if the D node is already overtly occupied, and if genitive case has already been assigned, there is no motivation for moving a genitive phrase to the D level. I also show that Germanic dative of possession constructions (possessor doubling) can be explained within the same framework. Finally, there is a brief discussion of the potential applicability of this analysis to Scandinavian.

Virtual Research Environments and Virtual Laboratories are among the key products the BlueBRIDGE project is called to develop and to deliver to serve its target communities and application scenarios. The deployment and operation of a Virtual Research Environment is a task that involves the reuse of existing technologies as well as the development of new technologies aiming at offering new facilities. The development of the technology, both the generic as well as that which is oriented to serve the specific needs of a given community/target scenario, is captured by other deliverables. This report describes the activities performed to provide the BlueBRIDGE community with the set of Virtual Research Environments (VREs) and Virtual Laboratories (VLabs) hosted by the BlueBRIDGE portal from September 2015 to November 2016. A total of 38 VREs VLabs have been deployed and operated, overall serving more than 1500 users across 22 countries. This requested to deal with approximately 600 tickets (32 tickets for VRE creationupdate, 244 requests for support, 315 requests for incidents and bugs).

Deliverable D9.1 - "BlueBRIDGE VRE Commons Facilities" reports the release of the BlueBRIDGE facilities for Data Access, Data Discovery, Data Storage, Data Analytics and Data Publishing. Those facilities are implemented through web services, libraries, and mediators over technologies that are offered as services operated and made accessible through VREs This deliverable is of type "Other" and consists of a set of wiki pages hosted by the BlueBRIDGE project wiki [1] plus a set of documentation pages for single facilities hosted by the gCube wiki [2].

The inverse scope of the negation marker in a sentence such as 'All the students have not read the book' has frequently been described in the literature, and various explanations have been offered for why the negation marker may (but need not) take scope over the more highly positioned QP. I will argue in this paper that the best explanation for this phenomenon is the Neg Stranding Hypothesis, according to which the subject of the sentence 'All the students have not read the book' with the [¬ > ∀] reading is the negated QP 'not all the students' and the negation marker has been stranded by the QP 'all the students'.

The iMarine Data Management Software comprises a number of components and subsystems offering facilities for accessing, transferring and harmonising a rich array of data typologies. This document describes the novelties within the iMarine Data Management Software from M12 (Oct.'12) to M27 (Jan.'14). It complements D9.2 [10] which describes iMarine Data Management Software up to M11 (Sept.'12). This deliverable is intended for documentation purposes only. The actual deliverable is represented by the software artifacts and their accompanying documentation.

iMarine Data Infrastructure Enabling Software contains the description of software and pointers to the documentation and artifacts of the related components that comprise the e-Infrastructure Management suite delivered from M11 to M24

The Germanic languages allow floating negated quantifiers (The children have not all not eaten) while the Romance languages do not. The Germanic languages also allow negation to take inverse scope over a universal quantifier (All the children have not eaten) whereas the Romance languages are very restrictive in their handling of ∀¬ word order. Based mainly on the theory of negation in Zeijlstra (2004), the Stranding Analysis of floating quantifiers of Sportiche (1988) and Giusti (1990), and the Neg Stranding Hypothesis of Cirillo (2009), it will be argued that these two differences between Germanic and Romance are attributable to one sole difference: Negation is a functional category in Romance but not in Germanic.

This dissertation examines in detail, the planning, conduct, and context of Allied Operational Command during the period from the Normandy Invasion to the end of Operation MARKET GARDEN, the airborne invasion of Holland. These campaigns were influenced by several factors: the nature of the Allied Coalition, the differing views and approach to battle of the separate services and the different nationalities within the coalition, and the actual conduct of battle within the context of a larger effort, the military campaign. The 1944c ampaignw as uniquei n that it representedth e two year evolution of a political-military coalition, whose campaign conduct in the field was overseen by a fully integratedh eadquartersa nd whose staff was composedo f memberso f both the individual services and separaten ationalities. While this headquartersp resenteda united front behind its admired commander, General Dwight D. Eisenhower. its competence to plan and control operations in anything but the broadest sense was challengeda t every turn by the air and ground commandersta skedt o fight the actual campaign. This dissertation concludes that the "oversight" provided by the Supreme Headquarters, Allied Expeditionary Force, SHAEF, and its Supreme Commander. was not in tune with both operational realities and practices. and was not capable of seizing opportunity and conducting a campaign of maneuver. During the actual execution of MARKET GARDEN, the Allied Command system functioned poorly causing the operation to fail by the narrowest margins. While MARKET GARDEN has often been portrayed as a failure of one man, of intelligence, or of poor planning, the coalition system and the men who ran it were not capable of fighting a complicated battle efficiently because of their inability to function as a team, rather than as a band of brothers, the creation of which was the responsibility of the Supreme Commander.

Linguists have for a long time been in two opposing camps regarding how to explain the phenomenon of floating quantifiers, exemplified in the following two sentences: (i) All the students have read the book. (ii) The students have all read the book. The quantifier all in (i) modifies the phrase the students. The question is what enables the quantifier to float away from the phrase that it modifies in (ii). For a long time, many linguists have believed that (i) and (ii) are unrelated. They have assumed that the subject in (i) is "all the students" and that the subject in (ii) is "the students," with "all" being a kind of adverb located in a typical adverbial position, right next to the verb phrase. This approach is usually called the Adverbial Approach to floating quantifiers. In 1988 a theory was developed whereby (i) and (ii) are the same sentence. Under this approach the subject of both sentences is "all the students," but in (ii) the phrase "the students" has moved to a higher position in the sentence and has stranded the quantifier next to the verb. This approach, called the Stranding Analysis, generated enthusiasm when it was first presented in 1988, but its success was short-lived. It was found to have weaknesses, and this caused many linguists to return to various adverbial approaches. Linguists are still very much divided on the subject. The purpose of this article is first of all to explain what the debate on floating quantifiers is all about and secondly to argue that if one updates the Stranding Analysis for more recent developments in generative linguistic theory, and if one considers more data in more languages, one will find that it is too early to write off the Stranding Analysis and declare the Adverbial Approach the winner.

Universal quantifiers such as all select a DP as their complement and can be ‘floated’ or ‘stranded’ by that DP, and in certain Germanic languages they can also co-occur with an interrogative DP. The purpose of this article is to investigate whether interrogative and non-interrogative DPs that co-occur with a universal quantifier in the Germanic languages have the same relationship to that quantifier and have gone through the same selection process. I begin with evidence from German that universal quantifiers can select and be stranded by interrogative as well as non-interrogative DPs, but I ultimately argue, going back to an analysis in Giusti (1990b), that a universal quantifier co-occurring with an interrogative is base-generated to the right of that interrogative, not to its left. I also propose that the formation of interrogative expressions involving universal quantifiers may take place in the syntax or in the lexicon, depending on the language.

We have examined the effects of cyclosporin A (CsA) and a series of CsA analogs that bind with decreasing affinity to cyclophilin, to evaluate the involvement of this protein in the release of preformed (histamine) and de novo synthesized (peptide leukotriene C4; LTC4) mediators of inflammatory reactions from human basophils. CsA (8 to 800 nM) concentration-dependently inhibited (5 to 60%) histamine release from peripheral blood basophils challenged with anti-IgE. CsA was more potent (92.6 +/- 1.8 vs 59.1 +/- 4.5%; p less than 0.001) and, at low concentrations, more effective when the channel-operated influx of Ca2+ was bypassed by the ionophore A23187 (IC40 = 24.1 +/- 3.9 vs 105.5 +/- 22.2 nM; p less than 0.05). CsA had no effect on the release of histamine caused by phorbol myristate and bryostatin 1 that activate different isoforms of protein kinase C. Inhibition of histamine release from basophils challenged with anti-IgE was not abolished by washing (three times) the cells before anti-IgE challenge. CsA also inhibited the de novo synthesis of LTC4 from basophils challenged with anti-IgE. The inhibitory effect of CsA was very rapid, and the drug, added from 1 to 10 min during the reaction, inhibited the ongoing release of histamine caused by anti-IgE and by A23187. The experiments with CsA analogs (CsG, CsC, CsD, and CsH) showed that CsH, which has an extremely low affinity for cyclophilin, has no effect on basophil mediator release. In addition, there is a significant correlation between the concentrations of CsA, G, C, and D that inhibited by 30% the histamine release induced by anti-IgE (r = 0.99; p less than 0.001) and by A23187 (r = 0.87; p less than 0.001) and their affinity for cyclophilin.

We have examined the effects of FK-506 and of the struturally related macrolide rapamycin, which bind with high affinity to a specific binding protein (FKBP), to evaluate the involvement of this protein in the release of preformed (histamine) and de novo synthesized inflammatory mediators (sulfidopeptide leukotriene C4 and prostaglandin D2) from mast cells isolated from human lung parenchyma. FK-506 (0.1 to 300 nM) concentration dependently inhibited histamine release from lung parenchymal mast cells activated by anti-IgE. FK-506 was more potent in lung mast cells than in basophils (IC50 = 1.13 +/- 0.46 nM vs 5.28 +/- 0.88 nM; p less than 0.001), whereas the maximal inhibitory effect was higher in basophils than in lung mast cells (88.4 +/- 2.5% vs 76.4 +/- 3.8%; p less than 0.01). FK-506 had little or no inhibitory effect on histamine release from lung mast cells challenged with compound A23187, whereas it completely suppressed A23187-induced histamine release from basophils. FK-506 also inhibited the de novo synthesis of 5-lipoxygenase (sulfidopeptide leukotriene C4) and cyclo-oxygenase (prostaglandin D2) metabolites of arachidonic acid from mast cells challenged with anti-IgE. Unlike in basophils, Il-3 (3 to 30 ng/ml) did not modify anti-IgE- or A23187-induced histamine release from lung mast cells nor did it reverse the inhibitory effect of FK-506. Rapamycin (3 to 300 nM) had little or no effect on the release of histamine from lung mast cells, but it was a competitive antagonist of the inhibitory effect of FK-506 on anti-IgE-induced histamine release from human mast cells with a dissociation constant of about 12 nM. These data indicate that FK-506 is a potent anti-inflammatory agent that acts on human lung mast cells presumably by binding to a receptor site (i.e., FKBP).

In the present study we developed an experimental model, resembling human atherosclerosis, by removing the endothelial layer in Watanabe heritable hyperlipidemic (WHHL) rabbits (10 months old) by application of cryodamage on the external surface of arterial vessels. In age-matched New Zealand white (NZW) rabbits, used as control, after two months following cryodamage, carotid artery and infrarenal segments of abdominal aorta did not show any particular change in the ultrastructure of vessel wall. In WHHL rabbits, two months after cryodamage, atherosclerotic lesions (fatty streaks and fibrous plaques) were observed in both arteries. Many lipid-laden endothelial cells, subendothelial foam cells and smooth muscle cells were found in cryodamaged areas. In some areas, the cap of plaques appeared to be thinned and ruptured. Increased number of collagen and elastic fibrils was also observed in atherosclerotic regions. We conclude that this simple technique on WHHL rabbits provides a model of atherosclerosis with a high degree of morphological similarity between the artificially-induced plaque and human atherosclerotic plaque.

The authors report on the use a new barium enema catheter employed in 398 patients from January, 1990 through June, 1991. Its innovative characteristics and several possible uses are compared with those of conventional equipment. Particularly, the advantages offered by the various possible placement sites of the catheter--i.e., the II duodenal portion and beyond the ligament of Treitx--are discussed, together with its different uses according to clinical symptoms: its best location is beyond the ligament of Treitz in subocclusions, versus in the II duodenal portion if tumors or other duodenal conditions are suspected. The new catheter exhibited 100% accuracy; the average exposure time for radioscopy during its positioning was 3 minutes. A selected group of 149 patients was examined for complications, which were few (8%), of poor importance, short and completely curable.

Forty-five patients with mediastinal spread of malignant, Hodgkin's and non-Hodgkin's lymphomas were examined with MR Imaging at 0.5 T. Ninety-two examinations were performed at diagnosis and/or during and after treatment to investigate MR capabilities in distinguishing fibrous tissue from active disease in the masses residuing after therapy--which cannot be done by means of CT. MR results indicated T2-weighted sequences to be the most useful. MR results were compared with the data collected from follow-up, clinics, and biology. MR Imaging had high accuracy (92.1%). The number of false negatives was very low, thanks to the low intensity of fibrous tissue, while a relatively high number of false positives was observed, probably due to the difficulties in discriminating inflammatory from neoplastic tissue.