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.

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.