Project Conclusion Report

verglichen mit
Diese Zeile wurde entfernt.
Dieses Wort wurde entfernt. Dieses Wort wurde hinzugefügt.
Diese Zeile wurde hinzugefügt.

Änderungen (12)

Seitenhistorie anzeigen

h1. References to the documentation environment (/)

{color:#000000}We start with a brief overview on the tools the project {color}{color:#000000}[team|]{color} {color:#000000}to collaborate. {color}{color:#000000}Our main platform for working together on the prototype has been{color} {color:#000000}[GitHub|]{color}{color:#000000}, a web-based service for software development projects that uses the Git revision control system. Occasionally (like for writing this report) we made use of the hbz's Confluence{color} {color:#000000}[wiki|]{color}{color:#000000}. We used the tool{color} {color:#000000}[Huboard|]{color} {color:#000000}that is based on the GitHub API to have an overview over the different tasks and their status. Thus, in the course of this report, several references will thus go to GitHub issues and comments where certain aspects are covered in more detail. The OER World Map itself can be found under{color} {color:#000000}[]{color} {color:#000000}.{color}

h1. Features of the hbz prototype (/)

Due to the short development time for the prototype the project concentrated on the realisation of an operational service, which allows to:
The hbz prototype consists of two applications (Drupal viewing/editing frontend and a JavaScript map) which are themselves based on an application programming interface (API) that enables programmatic interaction with the data. A detailed look at these three parts will follow. But first, the underlying data, its sources and data model will be described.

h2. Data (/)

h3. Sources (/)

The prototype is mostly based on data from two different sources:
Along with this data collected from pre-existing sources, there is also some manually added data.

h3. Data model (/)

We already noted in our [proposal|] that it wasn't clearly defined what kind of resources an OER world map should cover:
* 31 projects.

h3. Application profile (/)

We put some time into developing an [application profile|] (AP) using RDF for the OER world map. This application profile expresses the application's data model and configures how the data will be viewed in the Drupal editing and presentation environment (see below). In the future, it should also be used as a basis for validating the data input.
The application profile allows us to have configuration of the Drupal editing and presentation environment and future API validation in one central place. In order to configure the API validation and web site, changes have to be included into the application profile - all connected forms and presentation sites will automatically change accordingly. The AP is maintained on GitHub and enables relatively easy maintainance of the data presentation and validation without having to directly interact with the front end or API developer. (The application profile, in other words, _is_ the means of unambiguous communication between a metadata expert and the developers). This feature accelerates and cheapens the further development of the OER world map.

h2. API (/)

A central element of the hbz prototype is an application programming interface (API), which support the easy development of web applications on top of the data. The prototype's API can be found at []. Currently, there exist two clients (which are both integrated under are based on the API: a view and editing environment built with Drupal and a JavaScript map to interact with the data in a map environment. Multiple other applications could also be built on top of the API.
!api-use.png|border=1, width=250!

h2. Drupal view and editing environment (/)

The content management system (CMS) [Drupal|] is used to implement views and editing capabilities for the data provided by the API. Thus, we do not use the relational database that comes with Drupal. Instead, a so called [Entity Type|] was implemented to read/write from/to the API. Additionally, a custom [Entity Field Query|] was implemented to query the API. To demonstrate the use-case of linking to external data, the [GeoNames Search Webservice|] is also available via this component.

h2. JavaScript Map (/)

The JavaScript map is a separate read-only front-end based on [Leaflet|]. Although it is currently embedded in the Drupal site, it communicates directly with the API to fetch its data. Most filtering (i.e. by type and country) is done within the map's JavaScript at this point of the prototype. As the dataset grows, this filtering can be moved to the API to increase performance. As a pragmatic approach, the map's pop-ups reuse the views provided by Drupal. These views can be replaced by custom renderings in the future. To demontrate the advantages of linking to external datasets, country labels from the GeoNames data are provided in the language corresponding to the browser's settings. These multi-lingual labels are not part of the OER world map dataset, but retrieved from GeoNames using the Linked Open Data approach. Any updates to the GeoNames data will thus be reflected in the UI automatically.

h2. Out of scope (/)

Out of the scope of the project were:
* advanced features of the map design.

h1. Course of the project (-)

Our initial planning of the project within our proposal turned out to be quite resilient, although it`s strict linear character is misleading, since in fact we worked in several iterations which are difficult to display visually. The following table gives an overview of the course of the project including links to more detailed documentation on [GitHub|].
* Use remote context in JSON-LD served by the API ([\#44|])
* Implement basic JavaScript-based map ([\#39|])
* Implement search form in Drupal ({color:#ff0000}ticket Nummer?{color}) |
| Week 07: 24.03.14 - 30.03.14 \\ | *  Initial version of map interface | * Finish work on OCWC data transformation ([\#5|])
* Several adjustments to the application profile ([\#59|], [\#66|], [\#64|])