Connect to ADB
{% if page.last_updated %}Page last updated: {{page.last_updated}}
{% endif %} Site last generated: {{ site.time | date: "%b %-d, %Y" }}
-
-## Build the Theme
+HOBBIT is a distributed benchmarking platform designed for the unified execution of benchmarks for Linked Data solutions. The Hobbit benchmarking platform is based on the [FAIR data principles](https://www.go-fair.org/fair-principles/) and is the first benchmarking platform able to scale up to benchmarking real-world scenarios for Big Linked Data solutions.
-Follow these instructions to build the theme.
+- Benchmark your systems against one of HOBBIT benchmarks and compare it with others on our or your own cluster, or locally.
+- Implement and publish your own benchmarks.
+- Take part of periodically organized challenges.
-### 1. Download the theme
+### Quick start
-First, download or clone the theme from the [Github repo](https://github.com/tomjoht/documentation-theme-jekyll). Most likely you won't be pulling in updates once you start customizing the theme, so downloading the theme (instead of cloning it) probably makes the most sense. In Github, click the **Clone or download** button, and then click **Download ZIP**.
+Want to [take part in a challenge](/challenge_participation.html)?
-### 2. Install Jekyll
+Interested in [benchmarking your system](/benchmarking.html)?
-If you've never installed or run a Jekyll site locally on your computer, follow these instructions to install Jekyll:
+Eager to [deploy the platform](/quick_guide.html)?
-* [Install Jekyll on Mac][mydoc_install_jekyll_on_mac]
-* [Install Jekyll on Windows][mydoc_install_jekyll_on_windows]
+See [our YouTube channel with tutorials](https://www.youtube.com/channel/UC3eWNVAKXLqAdOhuQ5kd57g/).
-### 3. Install Bundler
+### Useful links
-In case you haven't installed Bundler, install it:
+Master instance of the HOBBIT platform, where public experiments and challenges take place:
+[master.project-hobbit.eu](https://master.project-hobbit.eu/).
-```
-gem install bundler
-```
+[`hobbit-project` GitHub organization](https://github.com/hobbit-project/) for HOBBIT development:
+- [HOBBIT Platform](https://github.com/hobbit-project/platform)
+- [HOBBIT Core Library](https://github.com/hobbit-project/core)
+- [HOBBIT RDF ontology](https://github.com/hobbit-project/ontology)
+- [this documentation](https://github.com/hobbit-project/hobbit-project.github.io)
-You'll want [Bundler](http://bundler.io/) to make sure all the Ruby gems needed work well with your project. Bundler sorts out dependencies and installs missing gems or matches up gems with the right versions based on gem dependencies.
+GitLab instance for benchmark and system developers:
+[git.project-hobbit.eu](https://git.project-hobbit.eu/).
-### 4. Option 1: Build the Theme (*without* the github-pages gem) {#option1}
+### Who should read this docs
-Use this option if you're not planning to publish your Jekyll site using [Github Pages](https://pages.github.com/).
+The documentation is primarily written for the people, who want to deploy the platform, system developers, benchmark developers and challenge organizers.
-Bundler's Gemfile specifies how project dependencies are managed. Although this project includes a Gemfile, this theme doesn't have any dependencies beyond core Jekyll. The Gemfile is used to list gems needed for publishing on Github Pages. **If you're not planning to have Github Pages build your Jekyll project, delete these two files from the theme's root directory:**
+### Citing
-* Gemfile
-* Gemfile.lock
-
-If you've never run Jekyll on your computer (you can check with `jekyll --version`), you may need to install the jekyll gem:
-
-```
-gem install jekyll
-```
-
-Now run jekyll serve (first change directories (`cd`) to where you downloaded the project):
-
-```
-jekyll serve
-```
-
-### 4. Option 2: Build the Theme (*with* the github-pages gem) {#option2}
-
-If you *are* in fact publishing on Github Pages, leave the Gemfile and Gemfile.lock files in the theme.The Gemfile tells Jekyll to use the github-pages gem. **However, note that you cannot use the normal `jekyll serve` command with this gem due to dependency conflicts between the latest version of Jekyll and Github Pages** (which are noted [briefly here](https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/)).
-
-You need Bundler to resolve these dependency conflicts. Use Bundler to install all the needed Ruby gems:
-
-```
-bundle update
-```
-
-Then *always* use this command to build Jekyll:
-
-```
-bundle exec jekyll serve
-```
-
-If you want to shorten this long command, you can put this code in a file such as jekyll.sh (on a Mac) and then simply type `. jekyll.sh` to build Jekyll.
-
-## Running the site in Docker
-
-You can also use Docker to directly build and run the site on your local machine. Just clone the repo and run the following from your working dir:
-```
-docker-compose build --no-cache && docker-compose up
-```
-The site should now be running at [http://localhost:4000/](http://localhost:4000/).
-
-This is perhaps the easiest way to see how your site would actually look.
-
-## Configure the sidebar
-
-There are several products in this theme. Each product uses a different sidebar. This is the essence of what makes this theme unique -- different sidebars for different product documentation. The idea is that when users are reading documentation for a specific product, the sidebar navigation should be specific to that product. (You can read more of my thoughts on why multiple sidebars are important in this [blog post](http://idratherbewriting.com/2016/03/23/release-of-documentation-theme-for-jekyll-50/).)
-
-The top navigation usually remains the same, because it allows users to navigate across products. But the sidebar navigation adapts to the product.
-
-In each page's frontmatter, you must specify the sidebar you want that page to use. Here's an example of the page frontmatter showing the sidebar property:
-
-
----
-title: Alerts
-tags: [formatting]
-keywords: notes, tips, cautions, warnings, admonitions
-last_updated: July 3, 2016
-summary: "You can insert notes, tips, warnings, and important alerts in your content. These notes are stored as shortcodes made available through the linksrefs.hmtl include."
-sidebar: mydoc_sidebar
-permalink: mydoc_alerts
----
-
-
-The `sidebar: mydoc_sidebar` refers to the \_data/sidebars/mydoc_sidebar.yml file.
-
-Note that your sidebar can only have 2 levels (expand the **Tag archives** option to see an example of the second level). Given that each product has its own sidebar, this depth should be sufficient (it's really like 3 levels). Deeper nesting goes against usability recommendations.
-
-You can optionally turn off the sidebar on any page (e.g. landing pages). To turn off the sidebar for a page, you should set the page frontmatter tag as `hide_sidebar: true`.
-
-If you don't declare a sidebar, the `home_sidebar` file gets used as the default because this is the default specified in the config file:
-
-```yaml
--
- scope:
- path: ""
- type: "pages"
- values:
- layout: "page"
- comments: true
- search: true
- sidebar: home_sidebar
- topnav: topnav
-```
-
-If you want to set different sidebar defaults based on different folders for your pages, specify your defaults like this:
-
-```
--
- scope:
- path: "pages/mydoc"
- type: "pages"
- values:
- layout: "page"
- comments: true
- search: true
- sidebar: mydoc_sidebar
- topnav: topnav
-```
-
-This would load the `mydoc_sidebar` for each file in **pages/mydoc**. You could set different defaults for different path scopes.
-
-For more detail on the sidebar, see [Sidebar navigation][mydoc_sidebar_navigation].
-
-## Top navigation
-
-The top navigation works just like the sidebar. You can specify which topnav data file should load by adding a `topnav` property in your page, like this:
-
-```yaml
-topnav: topnav
-```
-
-Here the topnav refers to the `_data/topnav.yml` file.
-
-Because most topnav options will be the same, the `_config.yml` file specifies the topnav file as a default:
-
-```yaml
--
- scope:
- path: ""
- type: "pages"
- values:
- layout: "page"
- comments: true
- search: true
- sidebar: home_sidebar
- topnav: topnav
-```
-
-## Sidebar syntax
-
-The sidebar data file uses a specific YAML syntax that you must follow. Follow the sample pattern shown in the theme, specically looking at `mydoc_sidebar.yml` as an example: Here's a code sample showing all levels:
-
-```yaml
-entries:
-- title: sidebar
- product: Jekyll Doc Theme
- version: 6.0
- folders:
- - title: Overview
- output: web, pdf
- folderitems:
-
- - title: Get started
- url: /index.html
- output: web, pdf
- type: homepage
-
- - title: Introduction
- url: /mydoc_introduction.html
- output: web, pdf
-
- - title: Release Notes
- output: web, pdf
- folderitems:
-
- - title: 6.0 Release notes
- url: /mydoc_release_notes_60.html
- output: web, pdf
-
- - title: 5.0 Release notes
- url: /mydoc_release_notes_50.html
- output: web, pdf
-
- - title: Tag archives
- output: web
- folderitems:
-
- - title: Tag archives overview
- url: /mydoc_tag_archives_overview.html
- output: web
-
- subfolders:
- - title: Tag archive pages
- output: web
- subfolderitems:
-
- - title: Formatting pages
- url: /tag_formatting.html
- output: web
-
- - title: Navigation pages
- url: /tag_navigation.html
- output: web
-
- - title: Content types pages
- url: /tag_content_types.html
- output: web
-```
-
-Each `folder` or `subfolder` must contain a `title` and `output` property. Each `folderitem` or `subfolderitem` must contain a `title`, `url`, and `output` property.
-
-The two outputs available are `web` and `pdf`. (Even if you aren't publishing PDF, you still need to specify `output: web`).
-
-The YAML syntax depends on exact spacing, so make sure you follow the pattern shown in the sample sidebars. See my [YAML tutorial](mydoc_yaml_tutorial) for more details about how YAML works.
-
-{% include note.html content="If you have just one character of spacing off, Jekyll won't build due to the YAML syntax error. You'll see an error message in your console that says \"Error ... did not find expected key while parsing a block mapping at line 22 column 5. Error: Run jekyll build --trace for more information.\" If you encounter this, it usually refers to incorrect indentation or spacing in the YAML file. See the example mydoc_sidebar.yml file to see where your formatting went wrong." %}
-
-Each level must have at least one topic before the next level starts. You can't have a second level that contains multiple third levels without having at least one standalone topic in the second level. If you need a hierarchy that has a folder that contains other folders and no loose topics, use a blank `-` item like this:
-
-```yaml
-entries:
-- title: sidebar
- product: Jekyll Doc Theme
- version: 6.0
- folders:
- - title: Overview
- output: web, pdf
- folderitems:
-
- -
-
- - title: Release Notes
- output: web, pdf
- folderitems:
-
- - title: 6.0 Release notes
- url: /mydoc_release_notes_60.html
- output: web, pdf
-
- - title: 5.0 Release notes
- url: /mydoc_release_notes_50.html
- output: web, pdf
-
- - title: Installation
- output: web, pdf
- folderitems:
-
- - title: About Ruby, Gems, Bundler, etc.
- url: /mydoc_about_ruby_gems_etc.html
- output: web, pdf
-
- - title: Install Jekyll on Mac
- url: /mydoc_install_jekyll_on_mac.html
- output: web, pdf
-
- - title: Install Jekyll on Windows
- url: /mydoc_install_jekyll_on_windows.html
- output: web, pdf
-```
-
-To accommodate the title page and table of contents in PDF outputs, each product sidebar must list these pages before any other:
-
-```yaml
-- title:
- output: pdf
- type: frontmatter
- folderitems:
- - title:
- url: /titlepage
- output: pdf
- type: frontmatter
- - title:
- url: /tocpage
- output: pdf
- type: frontmatter
-```
-
-Leave the output as `output: pdf` for these frontmatter pages so that they don't appear in the web output.
-
-For more detail on the sidebar, see [Sidebar navigation][mydoc_sidebar_navigation] and [YAML tutorial][mydoc_yaml_tutorial].
-
-## Comments
-
-The theme integrates [Commento.io](https://commento.io/) for comments below pages and posts. (This commenting service doesn't inject controversial tracking ads like Disqus does.) You will need to Commento.io account + plan ($5/month) to authorize Commento with your domain (no other configuration should be required). If you don't want comments, in the \_config.yml file, change the `comments: true` properties (under `defaults`) to `comments: false` in every instance. Then in the commento.html include file (inside \_includes), the `{% raw %}{% unless page.comments == false %} ... {% endunless %}{% endraw %}` logic will not insert the Commentio form.
-
-## Relative links and offline viewing
-
-This theme uses relative links throughout so that you can view the site offline and not worry about which server or directory you're hosting it. It's common with tech docs to push content to an internal server for review prior to pushing the content to an external server for publication. Because of the need for seamless transferrence from one host to another, the site has to use relative links.
-
-To view pages locally on your machine (without the Jekyll preview server), they need to have the `.html` extension. The `permalink` property in the page's frontmatter (without surrounding slashes) is what pushes the files into the root directory when the site builds.
-
-## Page frontmatter
-
-When you write pages, include these same frontmatter properties with each page:
-
-```yaml
----
-title: "Some title"
-tags: [sample1, sample2]
-keywords: keyword1, keyword2, keyword3
-last_updated: Month day, year
-summary: "optional summary here"
-sidebar: sidebarname
-permalink: filename.html
----
-```
-
-(You will customize the values for each of these properties, of course.)
-
-For titles, surrounding the title in quotes is optional, but if you have a colon in the title, you must surround the title with quotation marks. If you have a quotation mark inside the title, escape it first with a backlash `\`.
-
-Values for `keywords` get populated into the metadata of the page for SEO.
-
-Values for `tags` must be defined in your \_data/tags.yml list. You also need a corresponding tag file inside the tags folder that follows the same pattern as the other tag files shown in the tags folder. (Jekyll won't auto-create these tag files.)
-
-If you don't want the mini-TOC to show on a page (such as for the homepage or landing pages), add `toc: false` in the frontmatter.
-
-The `permalink` value should be the same as your filename and include the ".html" file extension.
-
-For more detail, see [Pages][mydoc_pages].
-
-## Where to store your documentation topics
-
-You can store your files for each product inside subfolders following the pattern shown in the theme. For example, product1, product2, etc, can be stored in their own subfolders inside the \_pages directory. Inside \_pages, you can store your topics inside sub-subfolders or sub-sub-folders to your heart's content. When Jekyll builds your site, it will pull the topics into the root directory and use the permalink for the URL.
-
-Note that product1, product2, and mydoc are all just sample content to demonstrate how to add multiple products into the theme. You can freely delete that content.
-
-For more information, see [Pages][mydoc_pages] and [Posts][mydoc_posts].
-
-## Configure the top navigation
-
-The top navigation bar's menu items are set through the \_data/topnav.yml file. Use the top navigation bar to provide links for navigating from one product to another, or to navigate to external resources.
-
-For external URLs, use `external_url` in the item property, as shown in the example topnav.yml file. For internal links, use `url` the same was you do in the sidebar data files.
-
-Note that the topnav has two sections: `topnav` and `topnav_dropdowns`. The topnav section contains single links, while the `topnav_dropdowns` section contains dropdown menus. The two sections are independent of each other.
-
-## Generating PDF
-
-If you want to generate PDF, you'll need a license for [Prince XML](http://www.princexml.com/). You will also need to [install Prince](http://www.princexml.com/doc/installing/). You can generate PDFs by product (but not for every product on the site combined together into one massive PDF). Prince will work even without a license, but it will imprint a small Prince image on the first page, and you're supposed to buy the license to use it.
-
-If you're on Windows, install [Git Bash client](https://git-for-windows.github.io/) rather than using the default Windows command prompt.
-
-Open up the css/printstyles.css file and customize the email address (`youremail@domain.com`) that is listed there. This email address appears in the bottom left footer of the PDF output. You'll also need to create a PDF configuration file following the examples shown in the pdfconfigs folder, and also customize some build scripts following the same pattern shown in the root: pdf-product1.sh
-
-See the section on [Generating PDFs][mydoc_generating_pdfs] for more details about setting the theme up for this output.
-
-## Blogs / News
-
-For blog posts, create your markdown files in the \_posts folder following the sample formats. Post file names always begin with the date (YYYY-MM-DD-title).
-
-The news/news.html file displays the posts, and the news_archive.html file shows a yearly history of posts. In documentation, you might use the news to highlight product features outside of your documentation, or to provide release notes and other updates.
-
-See [Posts][mydoc_posts] for more information.
-
-## Markdown
-
-This theme uses [kramdown markdown](http://kramdown.gettalong.org/). kramdown is similar to Github-flavored Markdown, except that when you have text that intercepts list items, the spacing of the intercepting text must align with the spacing of the first character after the space of a numbered list item. Basically, with your list item numbering, use two spaces after the dot in the number, like this:
-
-```
-1. First item
-2. Second item
-3. Third item
-```
-
-When you want to insert paragraphs, notes, code snippets, or other matter in between the list items, use four spaces to indent. The four spaces will line up with the first letter of the list item (the First or Second or Third).
-
-```
-1. First item
-
- ```
- alert("hello");
- ```
-
-2. Second item
-
- Some pig!
-
-3. Third item
-```
-
-See the topics under "Formatting" in the sidebar for more information.
-
-## Automated links
-
-If you want to use an automated system for managing links, see [Automated Links][mydoc_hyperlinks.html#automatedlinks]. This approach automatically creates a list of Markdown references to simplify linking.
-
-## Other instructions
-
-The content here is just a getting started guide only. For other details in working with the theme, see the various sections in the sidebar.
-
-{% include links.html %}
+[HOBBIT: A platform for benchmarking Big Linked Data](https://content.iospress.com/articles/data-science/ds190021)
diff --git a/js/jquery.navgoco.min.js b/js/jquery.navgoco.min.js
old mode 100755
new mode 100644
diff --git a/pages/docs/OAEI_2020.md b/pages/docs/OAEI_2020.md
new file mode 100644
index 000000000..2fec523e3
--- /dev/null
+++ b/pages/docs/OAEI_2020.md
@@ -0,0 +1,127 @@
+---
+title: OAEI 2020
+keywords: HOBBIT Documentation
+sidebar: main_sidebar
+toc: false
+permalink: OAEI_2020.html
+folder: docs
+---
+
+## Instance Matching or Link Discovery
+The number of datasets published in the Web of Data as part of the Linked Data Cloud is constantly increasing. The Linked Data paradigm is based on the unconstrained publication of information by different publishers, and the interlinking of Web resources across knowledge bases. In most cases, the cross-dataset links are not explicit in the dataset and must be automatically determined using Instance Matching (IM) and Link Discovery tools amongst others. The large variety of techniques requires their comparative evaluation to determine which one is best suited for a given context. Performing such an assessment generally requires well-defined and widely accepted benchmarks to determine the weak and strong points of the proposed techniques and/or tools.
+
+A number of real and synthetic benchmarks that address different data linking challenges have been proposed for evaluating the performance of such systems. So far, only a limited number of link discovery benchmarks target the problem of linking geo-spatial entities. However, some of the largest knowledge bases on the Linked Open Data Web are geospatial knowledge bases (e.g., LinkedGeoData with more than 30 billion triples). Linking spatial resources requires techniques that differ from the classical mostly string-based approaches. In particular, considering the topology of the spatial resources and the topological relations between them is of central importance to systems driven by spatial data.
+
+We believe that due to the large amount of available geospatial datasets employed in Linked Data and in several domains, it is critical that benchmarks for geospatial link discovery are developed.
+
+The proposed Task entitled “Instance Matching or Link Discovery Task” is presented at the OAEI OM 2020 Workshop at ISWC 2020. OM workshop conducts an extensive and rigorous evaluation of ontology matching and instance matching (link discovery) approaches through the OAEI (Ontology Alignment Evaluation Initiative) 2020 campaign.
+
+## Tasks and Training Data
+The aim of the Task is to test the performance of Link Discovery tools that implement string-based as well as topological approaches for identifying matching instances and spatial entities. The different frameworks will be evaluated for both accuracy (precision, recall and f-measure) and time performance.
+
+### SPIMBENCH
+
+The goal of the SPIMBENCH task is to determine when two instances describe the same Creative Work. A dataset is composed of a Tbox (contains the ontology and the instances) and corresponding Abox (contains only the instances). The datasets share almost the same ontology (with some difference in the properties’ level, due to the structure-based transformations). What we expect from participants. Participants are requested to match instances in the source dataset (Tbox1) against the instances of the target dataset (Tbox2). The task goal is to produce a set of mappings between the pairs of matching instances that are found to refer to the same real-world entity. An instance in the source (Tbox1) dataset can have none or one matching counterparts in the target dataset (Tbox2). We ask the participants to map only instances of Creative Works (http://www.bbc.co.uk/ontologies/creativework/NewsItem, http://www.bbc.co.uk/ontologies/creativework/BlogPost and http://www.bbc.co.uk/ontologies/creativework/Programme) and not the instances of the other classes.
+
+### Spatial
+
+We use the TomTom and Spaten datasets in order to create the appropriate benchmarks.
+
+TomTom provides a Synthetic Trace Generator developed in the context of the HOBBIT Project, that facilitates the creation of an arbitrary volume of data from statistical descriptions of vehicle traffic. More specifically, it generates traces, with a trace being a list of (longitude, latitude) pairs recorded by one device (phone, car, etc.) throughout one day. TomTom was the only data generator in the first version of SPgen.
+Spaten is an open-source configurable spatio-temporal and textual dataset generator, that can produce large volumes of data based on realistic user behavior. Spaten extracts GPS traces from realistic routes utilizing the Google Maps API, and combines them with real POIs and relevant user comments crawled from TripAdvisor. Spaten publicly offers GB-size datasets with millions of check-ins and GPS traces.
+This version of the challenge will comprise the Spatial task that measures how well the systems can identify DE-9IM (Dimensionally Extended nine-Intersection Model) topological relations [2]. The supported spatial relations are the following: Equals, Disjoint, Touches, Contains/Within, Covers/CoveredBy, Intersects, Crosses, Overlaps and the traces are represented in Well-known text (WKT) format. For each relation, a different pair of source and target dataset will be given to the participants.
+
+
+## Systems
+
+| Tool | Institution | Country | Contact person(s) | Task to participate |
+|----------------------------------------------------------|-------------------------------------|----------------|----------------------------------------------|---------------------|
+| An Efficient System for Matching Large Ontologies (Lily) | Southeast University | China | Wu Jiang-Heng | SPIMBENCH |
+| FTRL-IM | Tongji University | China | JIANG Yizhi | SPIMBENCH |
+| LogMap | City, University of London | UK | Ernesto Jimenez-Ruiz | SPIMBENCH |
+| Reffering Expressions for linking (REMiner) | LRI, Université Paris Saclay, CNRS | France | Armita Khajeh Nassiri | SPIMBENCH |
+| AgreementMakerLight (AML) | University of Lisbon / Instituto Gulbenkian de Ciencia / University of Illinois at Chicago | Portugal / USA | Daniel Faria, Catia Pesquita |SPIMBENCH, Spatial |
+| Rapid Discovery of Topological Relations (RADON) | AKSW | Germany | Mohamed Ahmed Sherif, Kevin Dreßler | Spatial |
+| Silk | National and Kapodistrian University of Athens | Greece | Despina Athanasia Pantazi, Panayiotis Smeros | Spatial |
+
+
+## Results
+
+### SPIMBENCH
+
+| SANDBOX (~380 instances, ~10000 triples) | | | | | |
+|-------------------------------------------|---------------|----------------------------|-----------------|-------------|-------------|
+| System | LogMap-HOBBIT | AgreementMakerLight-Hobbit | Lily_HOBBIT-2.2 | FTRLIM | REMiner-1.5 |
+| Fmeasure | 0.841328413 | 0.864516129 | 0.991708126 | 0.921417565 | 0.998324958 |
+| Precision | 0.938271605 | 0.834890966 | 0.983552632 | 0.854285714 | 1 |
+| Recall | 0.762541806 | 0.89632107 | 1 | 1 | 0.996655518 |
+| timePerformance | 7483 | 6446 | 2050 | 1525 | 7284 |
+
+| MAINBOX (~1800 instances, ~50000 triples) | | | | | |
+|-------------------------------------------|---------------|----------------------------|-----------------|-------------|-------------|
+| System | LogMap-HOBBIT | AgreementMakerLight-Hobbit | Lily_HOBBIT-2.2 | FTRLIM | REMiner-1.5 |
+| Fmeasure | 0.785635764 | 0.860457622 | 0.995388669 | 0.921478766 | 0.997681351 |
+| Precision | 0.880131363 | 0.838567839 | 0.990819672 | 0.85584563 | 0.99867374 |
+| Recall | 0.709463931 | 0.883520847 | 1 | 0.99801456 | 0.996690933 |
+| timePerformance | 26782 | 38772 | 3899 | 2247 | 33966 |
+
+The results can be found in HOBBIT platform: [here](https://master.project-hobbit.eu/challenges/http:%2F%2Fw3id.org%2Fhobbit%2Fchallenges%2381067bbe-defe-4b45-9027-52945f9199b7/experiments) (login as guest).
+
+### Spatial
+
+
+
+
+
+
+The results can be found in HOBBIT platform: [here](https://master.project-hobbit.eu/challenges/http:%2F%2Fw3id.org%2Fhobbit%2Fchallenges%236a436c70-4ed4-44f4-aeda-13bed8fd390c/experiments) (login as guest).
+
+## Organization
+### Organizing Committee
+* Pavel Shvaiko (Main contact), Trentino Digitale, Italy
+* Jérôme Euzenat, INRIA & Univ. Grenoble Alpes, France
+* Ernesto Jiménez-Ruiz, Univeristy of London, UK & SIRIUS, Univeristy of Oslo, Norway
+* Oktie Hassanzadeh, IBM Research, USA
+* Cássia Trojahn, IRIT, France
+
+### Program Committee (to be completed):
+* Alsayed Algergawy, Jena University, Germany
+* Manuel Atencia, INRIA & Univ. Grenoble Alpes, France
+* Zohra Bellahsene, LIRMM, France
+* Jiaoyan Chen, University of Oxford, UK
+* Valerie Cross, Miami University, USA
+* Jérôme David, University Grenoble Alpes & INRIA, France
+* Daniel Faria, Instituto Gulbenkian de Ciéncia, Portugal
+* Alfio Ferrara, University of Milan, Italy
+* Marko Gulić, University of Rijeka, Croatia
+* Wei Hu, Nanjing University, China
+* Ryutaro Ichise, National Institute of Informatics, Japan
+* Antoine Isaac, Vrije Universiteit Amsterdam & Europeana, Netherlands
+* Naouel Karam, Fraunhofer, Germany
+* Prodromos Kolyvakis, EPFL, Switzerland
+* Patrick Lambrix, Linköpings Universitet, Sweden
+* Oliver Lehmberg, University of Mannheim, Germany
+* Majeed Mohammadi, TU Delft, Netherlands
+* Peter Mork, MITRE, USA
+* Andriy Nikolov, Metaphacts GmbH, Germany
+* George Papadakis, University of Athens, Greece
+* Catia Pesquita, University of Lisbon, Portugal
+* Henry Rosales-Méndez, University of Chile, Chile
+* Kavitha Srinivas, IBM, USA
+* Giorgos Stoilos, Huawei Technologies, Greece
+* Pedro Szekely, University of Southern California, USA
+* Ludger van Elst, DFKI, Germany
+* Xingsi Xue, Fujian University of Technology, China
+* Ondřej Zamazal, Prague University of Economics, Czech Republic
+* Songmao Zhang, Chinese Academy of Sciences, China
+
+### Acknowledgements:
+We appreciate support from the Trentino as a Lab initiative of the European Network of the Living Labs at Trentino Digitale, the EU SEALS project, as well as the Pistoia Alliance Ontologies Mapping project and IBM Research.
+
+## Contact
+For more information send an e-mail to: Tzanina Saveta (jsaveta@ics.forth.gr) and Irini Fundulaki (fundul@ics.forth.gr).
+
+## References
+[1] Saveta, E. Daskalaki, G. Flouris, I. Fundulaki, and A. Ngonga-Ngomo. LANCE: Piercing to the Heart of Instance Matching Tools. In ISWC, 2015.
+
+[2] Christian Strobl. Encyclopedia of GIS , chapter Dimensionally Extended Nine-Intersection Model (DE-9IM), pages 240245. Springer, 2008.
diff --git a/pages/docs/OAEI_2021.md b/pages/docs/OAEI_2021.md
new file mode 100644
index 000000000..465d2cd10
--- /dev/null
+++ b/pages/docs/OAEI_2021.md
@@ -0,0 +1,184 @@
+---
+title: OAEI 2021
+keywords: HOBBIT Documentation
+sidebar: main_sidebar
+toc: false
+permalink: OAEI_2021.html
+folder: docs
+---
+
+## Instance Matching or Link Discovery
+The number of datasets published in the Web of Data as part of the Linked Data Cloud is constantly increasing. The Linked Data paradigm is based on the unconstrained publication of information by different publishers, and the interlinking of Web resources across knowledge bases. In most cases, the cross-dataset links are not explicit in the dataset and must be automatically determined using Instance Matching (IM) and Link Discovery tools amongst others. The large variety of techniques requires their comparative evaluation to determine which one is best suited for a given context. Performing such an assessment generally requires well-defined and widely accepted benchmarks to determine the weak and strong points of the proposed techniques and/or tools.
+
+A number of real and synthetic benchmarks that address different data linking challenges have been proposed for evaluating the performance of such systems. So far, only a limited number of link discovery benchmarks target the problem of linking geo-spatial entities. However, some of the largest knowledge bases on the Linked Open Data Web are geospatial knowledge bases (e.g., LinkedGeoData with more than 30 billion triples). Linking spatial resources requires techniques that differ from the classical mostly string-based approaches. In particular, considering the topology of the spatial resources and the topological relations between them is of central importance to systems driven by spatial data.
+
+We believe that due to the large amount of available geospatial datasets employed in Linked Data and in several domains, it is critical that benchmarks for geospatial link discovery are developed.
+
+The proposed Task entitled “Instance Matching or Link Discovery Task” is presented at the OAEI OM 2021 Workshop at ISWC 2021. OM workshop conducts an extensive and rigorous evaluation of ontology matching and instance matching (link discovery) approaches through the OAEI (Ontology Alignment Evaluation Initiative) 2021 campaign.
+
+## Tasks and Training Data
+The aim of the Task is to test the performance of Link Discovery tools that implement string-based as well as topological approaches for identifying matching instances and spatial entities. The different frameworks will be evaluated for both accuracy (precision, recall and f-measure) and time performance.
+
+### SPIMBENCH
+
+The goal of the SPIMBENCH task is to determine when two instances describe the same Creative Work. A dataset is composed of a Tbox (contains the ontology and the instances) and corresponding Abox (contains only the instances). The datasets share almost the same ontology (with some difference in the properties’ level, due to the structure-based transformations). What we expect from participants. Participants are requested to match instances in the source dataset (Tbox1) against the instances of the target dataset (Tbox2). The task goal is to produce a set of mappings between the pairs of matching instances that are found to refer to the same real-world entity. An instance in the source (Tbox1) dataset can have none or one matching counterparts in the target dataset (Tbox2). We ask the participants to map only instances of Creative Works (http://www.bbc.co.uk/ontologies/creativework/NewsItem, http://www.bbc.co.uk/ontologies/creativework/BlogPost and http://www.bbc.co.uk/ontologies/creativework/Programme) and not the instances of the other classes.
+
+You can download training data here: SPIMBENCH training data
+
+### Spatial
+
+We use the TomTom and Spaten datasets in order to create the appropriate benchmarks.
+
+TomTom provides a Synthetic Trace Generator developed in the context of the HOBBIT Project, that facilitates the creation of an arbitrary volume of data from statistical descriptions of vehicle traffic. More specifically, it generates traces, with a trace being a list of (longitude, latitude) pairs recorded by one device (phone, car, etc.) throughout one day. TomTom was the only data generator in the first version of SPgen.
+Spaten is an open-source configurable spatio-temporal and textual dataset generator, that can produce large volumes of data based on realistic user behavior. Spaten extracts GPS traces from realistic routes utilizing the Google Maps API, and combines them with real POIs and relevant user comments crawled from TripAdvisor. Spaten publicly offers GB-size datasets with millions of check-ins and GPS traces.
+This version of the challenge will comprise the Spatial task that measures how well the systems can identify DE-9IM (Dimensionally Extended nine-Intersection Model) topological relations [2]. The supported spatial relations are the following: Equals, Disjoint, Touches, Contains/Within, Covers/CoveredBy, Intersects, Crosses, Overlaps and the traces are represented in Well-known text (WKT) format. For each relation, a different pair of source and target dataset will be given to the participants.
+The Spatial Benchmark generator (Task 2) can be used to test the performance of systems that deal with topological relations proposed in the state of the art DE-9IM (Dimensionally Extended nine-Intersection Model) model [3].
+This benchmark generator implements all topological relations of DE-9IM between trajectories in the two dimensional space. To the best of our knowledge such a generic benchmark, that takes as input trajectories and checks the performance of linking systems for spatial data does not exist. For the design, we focused on (a) on the correct implementation of all the topological relations of the DE-9IM topological model and (b) on producing large datasets large enough to stress the systems under test. The supported relations are: Equals, Disjoint, Touches, Contains/Within, Covers/CoveredBy, Intersects, Crosses, Overlaps.
+
+Spatial task consists of two subtasks:
+
+- Task 2.1 : TomTom dataset
+
+ * 2.1.1 : Match LineStrings to LineString
+
+ * 2.1.2 : Match LineStrings to Polygons
+
+- Task 2.2 : Spaten dataset
+
+ * 2.2.1 : Match LineStrings to LineString
+
+ * 2.2.2 : Match LineStrings to Polygons
+
+The namespaces of the datasets are:
+- TomTom http://www.tomtom.com/ontologies/traces# for the Traces (LineStrings) and the namespace http://www.tomtom.com/ontologies/regions# for the Regions (Polygons)
+- Spaten http://www.spaten.com/ontologies/traces# for the Traces (LineStrings) and the namespace http://www.spaten.com/ontologies/regions# for the Regions (Polygons)
+
+You can download training data here: Spatial training data
+
+## Systems
+
+| Tool | Institution | Country | Contact person(s) | Task to participate |
+|----------------------------------------------------------|-------------------------------------|----------------|----------------------------------------------|---------------------|
+| An Efficient System for Matching Large Ontologies (Lily) | Southeast University | China | Peng Wang, Yunyan Hu, Shiyi Zou | SPIMBENCH |
+| LogMap | City, University of London | UK | Ernesto Jimenez-Ruiz | SPIMBENCH |
+| AgreementMakerLight (AML) | University of Lisbon / Instituto Gulbenkian de Ciencia / University of Illinois at Chicago | Portugal / USA | Daniel Faria, Catia Pesquita |SPIMBENCH, Spatial |
+| Distributed Spatial JedAI (DS-JedAI) | National and Kapodistrian University of Athens | Greece | Georgios Mandilaras | Spatial |
+| Rapid Discovery of Topological Relations (RADON) | AKSW | Germany | Mohamed Ahmed Sherif, Kevin Dreßler | Spatial |
+| Silk | National and Kapodistrian University of Athens | Greece | Despina Athanasia Pantazi, Panayiotis Smeros | Spatial |
+
+## Results
+
+### SPIMBENCH
+
+| SANDBOX (~380 instances, ~10000 triples) | | | |
+|-------------------------------------------|---------------|----------------------------|-----------------|
+| System | LogMap-HOBBIT | AgreementMakerLight-Hobbit | Lily_HOBBIT-2.2 |
+| Fmeasure | 0.841328413 | 0.864516129 | 0.991708126 |
+| Precision | 0.938271605 | 0.834890966 | 0.983552632 |
+| Recall | 0.762541806 | 0.89632107 | 1 |
+| timePerformance | 5699 | 7966 | 1845 |
+
+| MAINBOX (~1800 instances, ~50000 triples) | | | |
+|-------------------------------------------|---------------|----------------------------|-----------------|
+| System | LogMap-HOBBIT | AgreementMakerLight-Hobbit | Lily_HOBBIT-2.2 |
+| Fmeasure | 0.785635764 | 0.860457622 | 0.995388669 |
+| Precision | 0.880131363 | 0.838567839 | 0.990819672 |
+| Recall | 0.709463931 | 0.883520847 | 1 |
+| timePerformance | 27140 | 46517 | 3458 |
+
+The results can be found in HOBBIT platform: [here](https://master.project-hobbit.eu/challenges/http:%2F%2Fw3id.org%2Fhobbit%2Fchallenges%230f34a8c5-92b7-425c-8b42-a3c4426fd7a9/experiments) (login as guest).
+
+### Spatial
+
+
+
+
+
+
+Silk and GS-JedAI do not participate for COVERED BY and Silk does not participate also for COVERS.
+
+In order to make the diagrams more comprehensible we have excluded the extreme values.
+The excluded values are:
+
+- Task 2.2 : Spaten dataset, 2.2.1 : Match LineStrings to LineString (Sandbox):
+
+ relation: OVERLAPS, System: DS-JedAI, time performance: 724692 ms
+
+- Task 2.1 : TomTom dataset, 2.1.1 : Match LineStrings to LineString (Mainbox):
+
+ relation: TOUCHES, System: Silk, time performance: 2023852 ms
+
+ relation: TOUCHES, System: DS-JedAI, time performance: 3533541 ms
+
+ relation: INTERSECTS, System: Silk, time performance: 1602288 ms
+
+ relation: OVERLAPS, System: DS-JedAI, time performance: 949542 ms
+
+- Task 2.1 : TomTom dataset, 2.1.2 : Match LineStrings to Polygons (Mainbox):
+
+ relation: CONTAINS, System: AML, time performance: 2582081 ms
+
+ relation: WITHIN, System: AML, time performance: 2578691 ms
+
+ relation: COVERS, System: AML, time performance: 2564912 ms
+
+ relation: COVERED BY, System: AML, time performance: 2602657 ms
+
+
+If a result is empty but does not belong to one of the previous cases then the system has not been able to complete the specific task. The results can be found in HOBBIT platform: [here](https://master.project-hobbit.eu/challenges/http:%2F%2Fw3id.org%2Fhobbit%2Fchallenges%23a670106e-a127-4bb2-b612-857210d453a6/experiments) (login as guest).
+
+### Organizing Committee:
+* Pavel Shvaiko (Main contact)
+Trentino Digitale, Italy
+E-mail: pavel [dot] shvaiko [at] tndigit [dot] it
+* Jérôme Euzenat
+INRIA & Univ. Grenoble Alpes, France
+* Ernesto Jiménez-Ruiz
+City, Univeristy of London, UK & SIRIUS, Univeristy of Oslo, Norway
+Oktie Hassanzadeh
+IBM Research, USA
+* Cássia Trojahn
+IRIT, France
+
+### Program Committee:
+* Alsayed Algergawy, Jena University, Germany
+* Manuel Atencia, INRIA & Univ. Grenoble Alpes, France
+* Zohra Bellahsene, LIRMM, France
+* Jiaoyan Chen, University of Oxford, UK
+* Valerie Cross, Miami University, USA
+* Jérôme David, University Grenoble Alpes & INRIA, France
+* Gayo Diallo, University of Bordeaux, France
+* Daniel Faria, Instituto Gulbenkian de Ciéncia, Portugal
+* Alfio Ferrara, University of Milan, Italy
+* Marko Gulić, University of Rijeka, Croatia
+* Wei Hu, Nanjing University, China
+* Ryutaro Ichise, National Institute of Informatics, Japan
+* Antoine Isaac, Vrije Universiteit Amsterdam & Europeana, Netherlands
+* Naouel Karam, Fraunhofer, Germany
+* Prodromos Kolyvakis, EPFL, Switzerland
+* Patrick Lambrix, Linköpings Universitet, Sweden
+* Oliver Lehmberg, University of Mannheim, Germany
+* Fiona McNeill, Heriot Watt University, UK
+* Majid Mohammadi, Eindhoven University of Technology, Netherlands
+* Axel Ngonga, University of Paderborn, Germany
+* George Papadakis, University of Athens, Greece
+* Catia Pesquita, University of Lisbon, Portugal
+* Henry Rosales-Méndez, University of Chile, Chile
+* Kavitha Srinivas, IBM, USA
+* Pedro Szekely, University of Southern California, USA
+* Valentina Tamma, University of Liverpool, UK
+* Ludger van Elst, DFKI, Germany
+* Xingsi Xue, Fujian University of Technology, China
+* Ondřej Zamazal, Prague University of Economics, Czech Republic
+* Songmao Zhang, Chinese Academy of Sciences, China
+
+### Acknowledgements:
+We appreciate support from the Trentino as a Lab initiative of the European Network of the Living Labs at Trentino Digitale, the EU SEALS project, as well as the Pistoia Alliance Ontologies Mapping project and IBM Research.
+
+## Contact
+For more information send an e-mail to: Tzanina Saveta (jsaveta@ics.forth.gr) and Irini Fundulaki (fundul@ics.forth.gr).
+
+## References
+[1] Saveta, E. Daskalaki, G. Flouris, I. Fundulaki, and A. Ngonga-Ngomo. LANCE: Piercing to the Heart of Instance Matching Tools. In ISWC, 2015.
+
+[2] Christian Strobl. Encyclopedia of GIS , chapter Dimensionally Extended Nine-Intersection Model (DE-9IM), pages 240245. Springer, 2008.
diff --git a/pages/docs/OAEI_2022.md b/pages/docs/OAEI_2022.md
new file mode 100644
index 000000000..11be76908
--- /dev/null
+++ b/pages/docs/OAEI_2022.md
@@ -0,0 +1,147 @@
+---
+title: OAEI 2022
+keywords: HOBBIT Documentation
+sidebar: main_sidebar
+toc: false
+permalink: OAEI_2022.html
+folder: docs
+---
+
+## Instance Matching or Link Discovery
+The number of datasets published in the Web of Data as part of the Linked Data Cloud is constantly increasing. The Linked Data paradigm is based on the unconstrained publication of information by different publishers, and the interlinking of Web resources across knowledge bases. In most cases, the cross-dataset links are not explicit in the dataset and must be automatically determined using Instance Matching (IM) and Link Discovery tools amongst others. The large variety of techniques requires their comparative evaluation to determine which one is best suited for a given context. Performing such an assessment generally requires well-defined and widely accepted benchmarks to determine the weak and strong points of the proposed techniques and/or tools.
+
+A number of real and synthetic benchmarks that address different data linking challenges have been proposed for evaluating the performance of such systems. So far, only a limited number of link discovery benchmarks target the problem of linking geo-spatial entities. However, some of the largest knowledge bases on the Linked Open Data Web are geospatial knowledge bases (e.g., LinkedGeoData with more than 30 billion triples). Linking spatial resources requires techniques that differ from the classical mostly string-based approaches. In particular, considering the topology of the spatial resources and the topological relations between them is of central importance to systems driven by spatial data.
+
+We believe that due to the large amount of available geospatial datasets employed in Linked Data and in several domains, it is critical that benchmarks for geospatial link discovery are developed.
+
+The proposed Task entitled “Instance Matching or Link Discovery Task” is presented at the OAEI OM 2022 Workshop at ISWC 2022. OM workshop conducts an extensive and rigorous evaluation of ontology matching and instance matching (link discovery) approaches through the OAEI (Ontology Alignment Evaluation Initiative) 2022 campaign.
+
+## Tasks and Training Data
+The aim of the Task is to test the performance of Link Discovery tools that implement string-based as well as topological approaches for identifying matching instances and spatial entities. The different frameworks will be evaluated for both accuracy (precision, recall and f-measure) and time performance.
+
+### SPIMBENCH
+
+The goal of the SPIMBENCH task is to determine when two instances describe the same Creative Work. A dataset is composed of a Tbox (contains the ontology and the instances) and corresponding Abox (contains only the instances). The datasets share almost the same ontology (with some difference in the properties’ level, due to the structure-based transformations). What we expect from participants. Participants are requested to match instances in the source dataset (Tbox1) against the instances of the target dataset (Tbox2). The task goal is to produce a set of mappings between the pairs of matching instances that are found to refer to the same real-world entity. An instance in the source (Tbox1) dataset can have none or one matching counterparts in the target dataset (Tbox2). We ask the participants to map only instances of Creative Works (http://www.bbc.co.uk/ontologies/creativework/NewsItem, http://www.bbc.co.uk/ontologies/creativework/BlogPost and http://www.bbc.co.uk/ontologies/creativework/Programme) and not the instances of the other classes.
+
+You can download training data here: SPIMBENCH training data
+
+### Spatial
+
+We use the TomTom and Spaten datasets in order to create the appropriate benchmarks.
+
+TomTom provides a Synthetic Trace Generator developed in the context of the HOBBIT Project, that facilitates the creation of an arbitrary volume of data from statistical descriptions of vehicle traffic. More specifically, it generates traces, with a trace being a list of (longitude, latitude) pairs recorded by one device (phone, car, etc.) throughout one day. TomTom was the only data generator in the first version of SPgen.
+Spaten is an open-source configurable spatio-temporal and textual dataset generator, that can produce large volumes of data based on realistic user behavior. Spaten extracts GPS traces from realistic routes utilizing the Google Maps API, and combines them with real POIs and relevant user comments crawled from TripAdvisor. Spaten publicly offers GB-size datasets with millions of check-ins and GPS traces.
+This version of the challenge will comprise the Spatial task that measures how well the systems can identify DE-9IM (Dimensionally Extended nine-Intersection Model) topological relations [2]. The supported spatial relations are the following: Equals, Disjoint, Touches, Contains/Within, Covers/CoveredBy, Intersects, Crosses, Overlaps and the traces are represented in Well-known text (WKT) format. For each relation, a different pair of source and target dataset will be given to the participants.
+The Spatial Benchmark generator (Task 2) can be used to test the performance of systems that deal with topological relations proposed in the state of the art DE-9IM (Dimensionally Extended nine-Intersection Model) model [3].
+This benchmark generator implements all topological relations of DE-9IM between trajectories in the two dimensional space. To the best of our knowledge such a generic benchmark, that takes as input trajectories and checks the performance of linking systems for spatial data does not exist. For the design, we focused on (a) on the correct implementation of all the topological relations of the DE-9IM topological model and (b) on producing large datasets large enough to stress the systems under test. The supported relations are: Equals, Disjoint, Touches, Contains/Within, Covers/CoveredBy, Intersects, Crosses, Overlaps.
+
+Spatial task consists of two subtasks:
+
+- Task 2.1 : TomTom dataset
+
+ * 2.1.1 : Match LineStrings to LineStrings
+
+ * 2.1.2 : Match LineStrings to Polygons
+
+- Task 2.2 : Spaten dataset
+
+ * 2.2.1 : Match LineStrings to LineStrings
+
+ * 2.2.2 : Match LineStrings to Polygons
+
+The namespaces of the datasets are:
+- TomTom http://www.tomtom.com/ontologies/traces# for the Traces (LineStrings) and the namespace http://www.tomtom.com/ontologies/regions# for the Regions (Polygons)
+- Spaten http://www.spaten.com/ontologies/traces# for the Traces (LineStrings) and the namespace http://www.spaten.com/ontologies/regions# for the Regions (Polygons)
+
+You can download training data here: Spatial training data
+## Systems
+
+| Tool | Institution | Country | Contact person(s) | Task to participate |
+|----------------------------------------------------------|-------------------------------------|----------------|----------------------------------------------|---------------------|
+| LogMap | City, University of London | UK | Ernesto Jimenez-Ruiz | SPIMBENCH |
+| DLinker | IRD | France | HAPPI HAPPI Bill Gates |SPIMBENCH, Spatial |
+| Distributed Spatial JedAI (DS-JedAI) | National and Kapodistrian University of Athens | Greece | Georgios Mandilaras | Spatial |
+| Rapid Discovery of Topological Relations (RADON) | AKSW | Germany | Mohamed Ahmed Sherif, Kevin Dreßler | Spatial |
+| Silk | National and Kapodistrian University of Athens | Greece | Despina Athanasia Pantazi, Panayiotis Smeros | Spatial |
+
+## Results
+
+### SPIMBENCH
+
+| SANDBOX (~380 instances, ~10000 triples) | | |
+|-------------------------------------------|---------------|----------------------------|
+| System | LogMap-HOBBIT | DLinker |
+| Fmeasure | 0.841328413 | 0.702602230 |
+| Precision | 0.938271605 | 0.790794979 |
+| Recall | 0.762541806 | 0.63210702 |
+| timePerformance | 6116 | 15555 |
+
+| MAINBOX (~1800 instances, ~50000 triples) | |
+|-------------------------------------------|---------------|
+| System | LogMap-HOBBIT |
+| Fmeasure | 0.785635764 |
+| Precision | 0.880131363 |
+| Recall | 0.709463931 |
+| timePerformance | 24362 |
+
+DLinker only participated for the small dataset.
+
+The results can be found in HOBBIT platform: [here](https://master.project-hobbit.eu/challenges/http:%2F%2Fw3id.org%2Fhobbit%2Fchallenges%23543006e1-c797-47f7-b3b4-7480ba4cc856/experiments) (login as guest).
+### Spatial
+
+
+
+
+
+
+DLinker only participated for EQUALS and OVERLAPS for LineStrings to LineString.
+Silk and GS-JedAI do not participate for COVERED BY and Silk does not participate also for COVERS.
+
+In order to make the diagrams more comprehensible we have excluded the extreme values.
+The excluded values are:
+
+- Task 2.2 : Spaten dataset, 2.2.1 : Match LineStrings to LineString (Sandbox):
+
+ relation: OVERLAPS, System: DS-JedAI, time performance: 734129 ms
+
+- Task 2.1 : TomTom dataset, 2.1.1 : Match LineStrings to LineString (Mainbox):
+
+ relation: TOUCHES, System: Silk, time performance: 1827935 ms
+
+ relation: TOUCHES, System: DS-JedAI, time performance: 3859052 ms
+
+ relation: INTERSECTS, System: Silk, time performance: 1657319 ms
+
+ relation: OVERLAPS, System: DS-JedAI, time performance: 982780 ms
+
+If a result is empty but does not belong to one of the previous cases then the system has not been able to complete the specific task. The results can be found in HOBBIT platform: [here](https://master.project-hobbit.eu/challenges/http:%2F%2Fw3id.org%2Fhobbit%2Fchallenges%2332e6fed5-2a40-44e3-ad7b-3a916b445dab/experiments) (login as guest).
+
+## Challenge coordinators
+Ernesto Jimenez-Ruiz (ernesto [.] jimenez [.] ruiz [at] gmail [.] com)
+Daniel Faria (daniel [.] faria [.] 81 [at] gmail [.] com)
+
+## Evaluation platform chairs
+Sven Hertling (sven [at] informatik [.] uni-mannheim [.] de)
+Jan Portisch (jan [.] portisch [at] gmail [.] com)
+
+## Dissemination chairs
+Cassia Trojahn (cassia [.] trojahn [at] irit [.] fr)
+
+## Proceedings chairs
+Patrick Lambrix (patrick [.] lambrix [at] liu [.] se)
+Cassia Trojahn (cassia [.] trojahn [at] irit [.] fr)
+Daniel Faria (daniel [.] faria [.] 81 [at] gmail [.] com)
+
+## Publicity chairs
+Ernesto Jimenez-Ruiz(ernesto [.] jimenez [.] ruiz [at] gmail [.] com)
+Industry chairs
+Kavitha Srinivas (Kavitha [.] Srinivas [at] ibm [.] com)
+Ian Harrow (ianharrowconsulting [at] gmail [.] com)
+
+## Contact
+For more information send an e-mail to: Tzanina Saveta (jsaveta [at] ics [.] forth [.] gr) and Irini Fundulaki (fundul [at] ics [.] forth [.] gr).
+
+## References
+[1] Saveta, E. Daskalaki, G. Flouris, I. Fundulaki, and A. Ngonga-Ngomo. LANCE: Piercing to the Heart of Instance Matching Tools. In ISWC, 2015.
+
+[2] Christian Strobl. Encyclopedia of GIS , chapter Dimensionally Extended Nine-Intersection Model (DE-9IM), pages 240245. Springer, 2008.
diff --git a/pages/docs/OAEI_2023.md b/pages/docs/OAEI_2023.md
new file mode 100644
index 000000000..e7c700acd
--- /dev/null
+++ b/pages/docs/OAEI_2023.md
@@ -0,0 +1,103 @@
+---
+title: OAEI 2023
+keywords: HOBBIT Documentation
+sidebar: main_sidebar
+toc: false
+permalink: OAEI_2023.html
+folder: docs
+---
+
+## Instance Matching or Link Discovery
+The number of datasets published in the Web of Data as part of the Linked Data Cloud is constantly increasing. The Linked Data paradigm is based on the unconstrained publication of information by different publishers, and the interlinking of Web resources across knowledge bases. In most cases, the cross-dataset links are not explicit in the dataset and must be automatically determined using Instance Matching (IM) and Link Discovery tools amongst others. The large variety of techniques requires their comparative evaluation to determine which one is best suited for a given context. Performing such an assessment generally requires well-defined and widely accepted benchmarks to determine the weak and strong points of the proposed techniques and/or tools.
+
+A number of real and synthetic benchmarks that address different data linking challenges have been proposed for evaluating the performance of such systems. So far, only a limited number of link discovery benchmarks target the problem of linking geo-spatial entities. However, some of the largest knowledge bases on the Linked Open Data Web are geospatial knowledge bases (e.g., LinkedGeoData with more than 30 billion triples). Linking spatial resources requires techniques that differ from the classical mostly string-based approaches. In particular, considering the topology of the spatial resources and the topological relations between them is of central importance to systems driven by spatial data.
+
+We believe that due to the large amount of available geospatial datasets employed in Linked Data and in several domains, it is critical that benchmarks for geospatial link discovery are developed.
+
+The proposed Task entitled “Instance Matching or Link Discovery Task” is presented at the OAEI OM 2023 Workshop at ISWC 2023. OM workshop conducts an extensive and rigorous evaluation of ontology matching and instance matching (link discovery) approaches through the OAEI (Ontology Alignment Evaluation Initiative) 2023 campaign.
+
+## Tasks and Training Data
+The aim of the Task is to test the performance of Link Discovery tools that implement string-based as well as topological approaches for identifying matching instances and spatial entities. The different frameworks will be evaluated for both accuracy (precision, recall and f-measure) and time performance.
+
+### SPIMBENCH
+
+The goal of the SPIMBENCH task is to determine when two instances describe the same Creative Work. A dataset is composed of a Tbox (contains the ontology and the instances) and corresponding Abox (contains only the instances). The datasets share almost the same ontology (with some difference in the properties’ level, due to the structure-based transformations). What we expect from participants. Participants are requested to match instances in the source dataset (Tbox1) against the instances of the target dataset (Tbox2). The task goal is to produce a set of mappings between the pairs of matching instances that are found to refer to the same real-world entity. An instance in the source (Tbox1) dataset can have none or one matching counterparts in the target dataset (Tbox2). We ask the participants to map only instances of Creative Works (http://www.bbc.co.uk/ontologies/creativework/NewsItem, http://www.bbc.co.uk/ontologies/creativework/BlogPost and http://www.bbc.co.uk/ontologies/creativework/Programme) and not the instances of the other classes.
+
+You can download training data here: SPIMBENCH training data
+
+### Spatial
+
+We use the TomTom and Spaten datasets in order to create the appropriate benchmarks.
+
+TomTom provides a Synthetic Trace Generator developed in the context of the HOBBIT Project, that facilitates the creation of an arbitrary volume of data from statistical descriptions of vehicle traffic. More specifically, it generates traces, with a trace being a list of (longitude, latitude) pairs recorded by one device (phone, car, etc.) throughout one day. TomTom was the only data generator in the first version of SPgen.
+Spaten is an open-source configurable spatio-temporal and textual dataset generator, that can produce large volumes of data based on realistic user behavior. Spaten extracts GPS traces from realistic routes utilizing the Google Maps API, and combines them with real POIs and relevant user comments crawled from TripAdvisor. Spaten publicly offers GB-size datasets with millions of check-ins and GPS traces.
+This version of the challenge will comprise the Spatial task that measures how well the systems can identify DE-9IM (Dimensionally Extended nine-Intersection Model) topological relations [2]. The supported spatial relations are the following: Equals, Disjoint, Touches, Contains/Within, Covers/CoveredBy, Intersects, Crosses, Overlaps and the traces are represented in Well-known text (WKT) format. For each relation, a different pair of source and target dataset will be given to the participants.
+The Spatial Benchmark generator (Task 2) can be used to test the performance of systems that deal with topological relations proposed in the state of the art DE-9IM (Dimensionally Extended nine-Intersection Model) model [3].
+This benchmark generator implements all topological relations of DE-9IM between trajectories in the two dimensional space. To the best of our knowledge such a generic benchmark, that takes as input trajectories and checks the performance of linking systems for spatial data does not exist. For the design, we focused on (a) on the correct implementation of all the topological relations of the DE-9IM topological model and (b) on producing large datasets large enough to stress the systems under test. The supported relations are: Equals, Disjoint, Touches, Contains/Within, Covers/CoveredBy, Intersects, Crosses, Overlaps.
+
+Spatial task consists of two subtasks:
+
+- Task 2.1 : TomTom dataset
+
+ * 2.1.1 : Match LineStrings to LineStrings
+
+ * 2.1.2 : Match LineStrings to Polygons
+
+- Task 2.2 : Spaten dataset
+
+ * 2.2.1 : Match LineStrings to LineStrings
+
+ * 2.2.2 : Match LineStrings to Polygons
+
+The namespaces of the datasets are:
+- TomTom http://www.tomtom.com/ontologies/traces# for the Traces (LineStrings) and the namespace http://www.tomtom.com/ontologies/regions# for the Regions (Polygons)
+- Spaten http://www.spaten.com/ontologies/traces# for the Traces (LineStrings) and the namespace http://www.spaten.com/ontologies/regions# for the Regions (Polygons)
+
+You can download training data here: Spatial training data
+
+## Implementation
+In order to prepare your system to be benchmarked within the HOBBIT platform you must follow the instructions provided here.
+
+### SPIMBENCH
+An example of LIMES [3] as system adapter for SPIMBENCH can be found here.
+The system.ttl for the system adapter can be found here.
+
+You can also find an exaple of LogMap wrapping for HOBBIT here .
+
+The URI of the benchmark API, the system implements is **hobbit:implementsAPI bench:LinkingAPI;**
+
+### Spatial
+An example of LIMES [3] as system adapter for Spatial can be found here.
+The system.ttl for the system adapter can be found here.
+
+The URI of the benchmark API, the system implements is **hobbit:implementsAPI bench:SpatialAPI;**
+
+## Evaluation
+The performance metric(s) in a benchmark determine the effectiveness and efficiency of the systems and tools. In SPIMBENCH and Spatial benchmark, we focus on the quality of the output in terms of standard metrics such as precision, recall and f-measure. We also aim to quantify the performance (in ms) of the systems measuring the time needed to return all the results.
+
+
+## Challenge coordinators
+TBA
+
+## Evaluation platform chairs
+TBA
+
+## Dissemination chairs
+TBA
+
+## Proceedings chairs
+TBA
+
+## Publicity chairs
+TBA
+
+## Contact
+For more information send an e-mail to: Tzanina Saveta (jsaveta [at] ics [.] forth [.] gr) and Irini Fundulaki (fundul [at] ics [.] forth [.] gr).
+
+## References
+[1] Saveta, E. Daskalaki, G. Flouris, I. Fundulaki, and A. Ngonga-Ngomo. LANCE: Piercing to the Heart of Instance Matching Tools. In ISWC, 2015.
+
+[2] Christian Strobl. Encyclopedia of GIS , chapter Dimensionally Extended Nine-Intersection Model (DE-9IM), pages 240245. Springer, 2008.
+
+[3] Axel-Cyrille Ngonga Ngomo. On link discovery using a hybrid approach. Journal on Data Semantics, 1(4):203–217, 2012.
diff --git a/pages/docs/analysis_component.md b/pages/docs/analysis_component.md
new file mode 100644
index 000000000..3e9c80b69
--- /dev/null
+++ b/pages/docs/analysis_component.md
@@ -0,0 +1,12 @@
+---
+title: Analysis Component
+keywords: HOBBIT Documentation
+sidebar: main_sidebar
+toc: false
+permalink: analysis_component.html
+folder: docs
+---
+
+This component is triggered after an experiment has been carried out successfully.
+Its task is to enhance the benchmark results by combining them with the features of the benchmarked system and the data or task generators.
+These combination can lead to additional insights, e.g., strengths and weaknesses of a certain system.
diff --git a/pages/docs/benchmark_integration.md b/pages/docs/benchmark_integration.md
new file mode 100644
index 000000000..d09124312
--- /dev/null
+++ b/pages/docs/benchmark_integration.md
@@ -0,0 +1,261 @@
+---
+title: How to integrate a Benchmark
+keywords: HOBBIT Documentation
+sidebar: main_sidebar
+toc: false
+permalink: benchmark_integration.html
+folder: docs
+---
+
+This article shows how to use the provided abstract classes to implement the different benchmark components using the interfaces and classes from the [core library](https://github.com/hobbit-project/core) of the HOBBIT platform. The role of the different components is described in the [overview article](/overview.html) If you haven't took a look at the [general development of a component in java](/java_components.html) you should do this before reading this article.
+
+* [Data Generator](#data-generator)
+* [Task Generator](#task-generator)
+* [Evaluation Module](#evaluation-module)
+* [Benchmark Controller](#benchmark-controller)
+* [Adaptations](#adaptations)
+ * [Sequential tasks](#sequential-tasks)
+
+## Data Generator
+The data generator is the component that creates the dataset the benchmark is using.
+
+```java
+public class ExampleDataGenrator extends AbstractDataGenerator {
+
+ @Override
+ public void init() throws Exception {
+ // Always init the super class first!
+ super.init();
+
+ // Your initialization code comes here...
+ }
+
+ @Override
+ protected void generateData() throws Exception {
+ // Create your data inside this method. You might want to use the
+ // id of this data generator and the number of all data generators
+ // running in parallel.
+ int dataGeneratorId = getGeneratorId();
+ int numberOfGenerators = getNumberOfGenerators();
+
+ byte[] data;
+ while(notEnoughDataGenerated) {
+ // Create your data here
+ data = ...
+
+ // the data can be sent to the task generator(s) ...
+ sendDataToTaskGenerator(data);
+ // ... and/or to the system
+ sendDataToSystemAdapter(data);
+ }
+ }
+
+ @Override
+ public void close() throws IOException {
+ // Free the resources you requested here
+ ...
+
+ // Always close the super class after yours!
+ super.close();
+ }
+
+}
+```
+
+## Task Generator
+The task generator is the component that creates tasks based on the incoming data.
+
+```java
+public class ExampleTaskGenrator extends AbstractTaskGenerator {
+
+ @Override
+ public void init() throws Exception {
+ // Always init the super class first!
+ super.init();
+
+ // Your initialization code comes here...
+ }
+
+ @Override
+ protected void generateTask(byte[] data) throws Exception {
+ // Create tasks based on the incoming data inside this method.
+ // You might want to use the id of this task generator and the
+ // number of all task generators running in parallel.
+ int dataGeneratorId = getGeneratorId();
+ int numberOfGenerators = getNumberOfGenerators();
+
+ // Create an ID for the task
+ String taskId = getNextTaskId();
+
+ // Create the task and the expected answer
+ byte[] taskData = ...;
+ byte[] expectedAnswerData = ...;
+
+ // Send the task to the system (and store the timestamp)
+ long timestamp = System.currentTimeMillis();
+ sendTaskToSystemAdapter(taskId, taskData);
+
+ // Send the expected answer to the evaluation store
+ sendTaskToEvalStorage(taskId, timestamp, expectedAnswerData);
+ }
+
+ @Override
+ public void close() throws IOException {
+ // Free the resources you requested here
+ ...
+
+ // Always close the super class after yours!
+ super.close();
+ }
+
+}
+```
+Note, that the `generateTask(byte[] data)` method is called with the data that has been received in one single message coming from a data generator.
+
+
+## Evaluation Module
+The evaluation module is the component that evaluates the results that have been received from the benchmarked system. It operates in two phases. During the first phase, the module iterates over the single tasks and their expected answers (created by the task generator(s)) as well as the answers coming from the benchmarked system. For every pair, the method `evaluateResponse` is called.
+
+After all available pairs have been seen, the `summarizeEvaluation` method is called and should return an RDF model containing the values of the KPIs of the experiment.
+
+```java
+public class ExampleEvaluationModule extends AbstractEvaluationModule {
+
+ @Override
+ public void init() throws Exception {
+ // Always init the super class first!
+ super.init();
+
+ // Your initialization code comes here...
+ }
+
+ @Override
+ protected void evaluateResponse(byte[] expectedData, byte[] receivedData, long taskSentTimestamp, long responseReceivedTimestamp) throws Exception {
+ // evaluate the given response and store the result, e.g., increment internal counters
+ ...
+ }
+
+ @Override
+ protected Model summarizeEvaluation() throws Exception {
+ // All tasks/responsens have been evaluated. Summarize the results,
+ // write them into a Jena model and send it to the benchmark controller.
+ Model model = createDefaultModel();
+ Resource experimentResource = mode.getResource(experimentUri);
+ model.add(experimentResource , RDF.type, HOBBIT.Experiment);
+ ...
+ return model;
+ }
+
+ @Override
+ public void close() throws IOException {
+ // Free the resources you requested here
+ ...
+
+ // Always close the super class after yours!
+ super.close();
+ }
+
+}
+```
+
+The following information do not have to be added to the result RDF model since they will be added by the platform.
+* The platform version
+* The time at which the execution of the experiment started
+* The RDF model of the involved benchmark
+* The values of the configured benchmark parameters
+* The RDF model of the involved system instance and its system (if a meta system is defined)
+
+## Benchmark Controller
+The benchmark controller is used to create and orchestrate all other components needed to execute the benchmark.
+
+Note that for the creation of benchmark components it is recommended to use the methods that are offered for the different types of components instead of using the more general `createContainer` method. This is caused by internal states of the `AbstractBenchmarkController` class that for example tracks the number of data generators that it has created.
+
+```java
+public class ExampleBenchmarkController extends AbstractBenchmarkController {
+
+
+ @Override
+ public void init() throws Exception {
+ super.init();
+
+ // Your initialization code comes here...
+
+ // You might want to load parameters from the benchmarks parameter model
+ NodeIterator iterator = benchmarkParamModel.listObjectsOfProperty(benchmarkParamModel
+ .getProperty("http://example.org/myParameter"));
+
+ // Create the other components
+
+ // Create data generators
+ String dataGeneratorImageName = "example-data-generator";
+ int numberOfDataGenerators = ...;
+ String[] envVariables = new String[]{"key1=value1", ...};
+ createDataGenerators(dataGeneratorImageName, numberOfDataGenerators, envVariables);
+
+ // Create task generators
+ String taskGeneratorImageName = "example-task-generator";
+ int numberOfTaskGenerators = ...;
+ envVariables = new String[]{"key1=value1", ...};
+ createTaskGenerators(taskGeneratorImageName, numberOfTaskGenerators, envVariables);
+
+ // Create evaluation storage
+ createEvaluationStorage();
+
+ // Wait for all components to finish their initialization
+ waitForComponents();
+ }
+
+ @Override
+ protected void executeBenchmark() throws Exception {
+ // give the start signals
+ sendToCmdQueue(Commands.TASK_GENERATOR_START_SIGNAL);
+ sendToCmdQueue(Commands.DATA_GENERATOR_START_SIGNAL);
+
+ // wait for the data generators to finish their work
+ waitForDataGenToFinish();
+
+ // wait for the task generators to finish their work
+ waitForTaskGenToFinish();
+
+ // wait for the system to terminate. Note that you can also use
+ // the method waitForSystemToFinish(maxTime) where maxTime is
+ // a long value defining the maximum amount of time the benchmark
+ // will wait for the system to terminate.
+ waitForSystemToFinish();
+
+ // Create the evaluation module
+ String evalModuleImageName = "example-eval-module";
+ String[] envVariables = new String[]{"key1=value1", ...};
+ createEvaluationModule(evalModuleImageName, envVariables);
+
+ // wait for the evaluation to finish
+ waitForEvalComponentsToFinish();
+
+ // the evaluation module should have sent an RDF model containing the
+ // results. We should add the configuration of the benchmark to this
+ // model.
+ // this.resultModel.add(...);
+
+ // Send the resultModul to the platform controller and terminate
+ sendResultModel(resultModel);
+ }
+
+ @Override
+ public void close() throws IOException {
+ // Free the resources you requested here
+ ...
+
+ // Always close the super class after yours!
+ super.close();
+ }
+
+}
+```
+
+## Adaptations
+The workflow described above can be further adapted to different scenarios.
+
+### Sequential tasks
+For some use cases it is important that the task generator sends the tasks sequentially, waiting for the current task to be finished before the next task can be started. To achieve such a behaviour the task generator and the evaluation storage have to be synchronized. This can be done by
+1. extending the `AbstractSequencingTaskGenerator` for implementing the task generator and
+2. starting the evaluation storage with the environmental variable `"ACKNOWLEDGEMENT_FLAG=true"`
diff --git a/pages/docs/benchmark_integration_api.md b/pages/docs/benchmark_integration_api.md
new file mode 100644
index 000000000..b5f8f22ac
--- /dev/null
+++ b/pages/docs/benchmark_integration_api.md
@@ -0,0 +1,292 @@
+---
+title: Integrating a Benchmark
+keywords: HOBBIT Documentation
+sidebar: main_sidebar
+toc: false
+permalink: benchmark_integration_api.html
+folder: docs
+---
+
+This article describes the general API the platform offers for a benchmark. Note that in addition to this API, the benchmark might define an own API for the communication with the system.
+
+The API of the platform for a benchmark comprises three parts.
+1. There are some details that should be taken into account when defining the benchmark container image.
+2. The platform controller offers some functionalities which can be used by the benchmark to create new containers and stop them.
+3. Every benchmark needs to be described in a meta data file which gives the platform the necessary information about the benchmark.
+
+## Benchmark controller container
+
+There is one main container that will represent the benchmark (from the platforms point of view). Although the benchmark can comprise several containers, the platform will observe this main container and react on its termination - regardless whether other containers still exist or not.
+
+### Container start
+
+A benchmark controller might comprise more than one container. However, it needs to have exactly __one main container__. This container will be created by the platform controller including the following environmental variables:
+
+|- Variable name -|- Meaning -|
+|---|---|
+| `HOBBIT_RABBIT_HOST` | The DNS name of the RabbitMQ instance which is used for communicating to the platform controller, e.g, via the [command queue](command_queue). |
+| `HOBBIT_SESSION_ID` | The ID of the current experiment. It is necessary for the usage of the [command queue](command_queue). |
+| `BENCHMARK_PARAMETERS_MODEL_KEY` | The benchmark model from the meta data file serialized as `JSON-LD` string. |
+| `HOBBIT_EXPERIMENT_URI` | The URI of the experiment which should be used to generate the result model. |
+
+After the container started, the platform assumes that it will connect itself to the command queue.
+
+#### Benchmark parameters
+
+As described below, a benchmark can define parameters which can be configured before starting an experiment. These parameters are submitted to the benchmark controller container as [RDF](https://www.w3.org/2001/sw/wiki/RDF) model within the `BENCHMARK_PARAMETERS_MODEL_KEY` environmental variable. For reading the parameters, it is necessary to understand the content of the model.
+
+The parameters will be defined as properties in the benchmark meta data file which is described below. Therefore, every parameter has an own URI and a defined value range. The parameter model contains triples like
+```turtle
+This is my note.
--def foo(x):-{{site.data.alerts.end}}{% endraw %} -``` - -**Result:** - -{{site.data.alerts.note}} -
- return x+1 -
This is my note.
--def foo(x):-{{site.data.alerts.end}} - -The same Bootstrap code from the alert is stored in yaml files inside the \_data folder. (This was how I previously implemented this code, but since this method was prone to error and didn't trigger any build warnings or failures when incorrectly coded, I changed the approach to use includes instead.) - -## Types of alerts available - -There are four types of alerts you can leverage: - -* note.html -* tip.html -* warning.html -* important.html - -They function the same except they have a different color, icon, and alert word. You include the different types by selecting the include template you want. Here are samples of each alert: - -{% include note.html content="This is my note." %} - -{% include tip.html content="This is my tip." %} - -{% include warning.html content="This is my warning." %} - -{% include important.html content="This is my important info." %} - -These alerts leverage includes stored in the \_include folder. The `content` option is a parameter that you pass to the include. In the include, the parameter is passed like this: - -``` -{% raw %}
- return x+1 -
If you want to use an FAQ format, use the syntax shown on the faq.html page. Rather than including code samples here (which are bulky with a lot of nested div tags), just look at the source in the mydoc_faq.html theme file.
output: web (rather than output: pdf) in the list of attributes in your sidebar. The prince-list.txt file that loops through the mydoc_sidebar.yml file to grab the URLs of each page that should appear in the PDF will skip over any items that do not list output: pdf in the item attributes. For example, you might not want your tag archives to appear in the PDF, but you probably will want to list them in the online help navigation." %}
-
-## 4. Customize your headers and footers
-
-Open up the css/printstyles.css file and customize what you want for the headers and footers. At the very least, customize the email address (`youremail@domain.com`) that appears in the bottom left.
-
-Exactly how the print styling works here is pretty nifty. You don't need to understand the rest of the content in this section unless you want to customize your PDFs to look different from what I've configured. But I'm adding this information here in case you want to understand how to customize the look and feel of the PDF output.
-
-This style creates a page reference for a link:
-
-{% raw %}
-```css
-a[href]::after {
- content: " (page " target-counter(attr(href), page) ")"
-}
-```
-
-You don't want cross references for any link that doesn't reference another page, so this style specifies that the content after should be blank:
-
-```css
-a[href*="mailto"]::after, a[data-toggle="tooltip"]::after, a[href].noCrossRef::after {
- content: "";
-}
-```
-{% endraw %}
-
-{% include tip.html content="If you have a link to a file download, or some other link that shouldn't have a cross reference (such as link used in JavaScript for navtabs or collapsible sections, for example, add `noCrossRef` as a class to the link to avoid having it say \"page 0\" in the cross reference." %}
-
-This style specifies that after links to web resources, the URL should be inserted instead of the page number:
-
-```css
-a[href^="http:"]::after, a[href^="https:"]::after {
- content: " (" attr(href) ")";
-}
-```
-
-This style sets the page margins:
-
-```css
-@page {
- margin: 60pt 90pt 60pt 90pt;
- font-family: sans-serif;
- font-style:none;
- color: gray;
-
-}
-```
-
-To set a specific style property for a particular page, you have to name the page. This allows Prince to identify the page.
-
-First you add frontmatter to the page that specifies the type. For the titlepage.html, here's the frontmatter:
-
-```yaml
----
-type: title
----
-```
-
-For the tocpage, here's the frontmatter:
-
-```yaml
----
-type: frontmatter
----
-```
-
-For the index.html page, we have this type tag (among others):
-
-```yaml
----
-type: first_page
----
-```
-
-The default_print.html layout will change the class of the `body` element based on the type value in the page's frontmatter:
-
-{% raw %}
-```liquid
-
-```
-{% endraw %}
-
-Now in the css/printstyles.css file, you can assign a page name based on a specific class:
-
-```css
-body.title { page: title }
-```
-
-This means that for content inside of `body class="title"`, we can style this page in our stylesheet using `@page title`.
-
-Here's how that title page is styled:
-
-```css
-@page title {
- @top-left {
- content: " ";
- }
- @top-right {
- content: " "
- }
- @bottom-right {
- content: " ";
- }
- @bottom-left {
- content: " ";
- }
-}
-```
-
-As you can see, we don't have any header or footer content, because it's the title page.
-
-For the tocpage.html, which has the `type: frontmatter`, this is specified in the stylesheet:
-
-```css
-body.frontmatter { page: frontmatter }
-body.frontmatter {counter-reset: page 1}
-
-
-@page frontmatter {
- @top-left {
- content: prince-script(guideName);
- }
- @top-right {
- content: prince-script(datestamp);
- }
- @bottom-right {
- content: counter(page, lower-roman);
- }
- @bottom-left {
- content: "youremail@domain.com"; }
-}
-```
-
-With `counter(page, lower-roman)`, we reset the page count to 1 so that the title page doesn't start the count. Then we also add some header and footer info. The page numbers start counting in lower-roman numerals.
-
-Finally, for the first page (which doesn't have a specific name), we restart the counting to 1 again and this time use regular numbers.
-
-```css
-body.first_page {counter-reset: page 1}
-
-h1 { string-set: doctitle content() }
-
-@page {
- @top-left {
- content: string(doctitle);
- font-size: 11px;
- font-style: italic;
- }
- @top-right {
- content: prince-script(datestamp);
- font-size: 11px;
- }
-
- @bottom-right {
- content: "Page " counter(page);
- font-size: 11px;
- }
- @bottom-left {
- content: prince-script(guideName);
- font-size: 11px;
- }
-}
-```
-
-You'll see some other items in there such as `prince-script`. This means we're using JavaScript to run some functions to dynamically generate that content. These JavaScript functions are located in the \_includes/head_print.html:
-
-```js
-
-
-
-```
-
-There are a couple of Prince functions that are default functions from Prince. This gets the heading title of the page:
-
-```js
- content: string(doctitle);
-```
-
-This gets the current page:
-
-```js
- content: "Page " counter(page);
-```
-
-Because the theme uses JavaScript in the CSS, you have to add the `--javascript` tag in the Prince command (detailed later on this page).
-
-## 5. Customize and run the PDF script
-
-Duplicate the pdf-mydoc.sh file in the root directory and customize it for your specific configuration files.
-
-```
-echo 'Killing all Jekyll instances'
-kill -9 $(ps aux | grep '[j]ekyll' | awk '{print $2}')
-clear
-
-echo "Building PDF-friendly HTML site for Mydoc ...";
-jekyll serve --detach --config _config.yml,pdfconfigs/config_mydoc_pdf.yml;
-echo "done";
-
-echo "Building the PDF ...";
-prince --javascript --input-list=_site/pdfconfigs/prince-list.txt -o pdf/mydoc.pdf;
-echo "done";
-```
-
-Note that the first part kills all Jekyll instances. This way you won't try to serve Jekyll at a port that is already occupied.
-
-The `jekyll serve` command serves up the HTML-friendly PDF configurations for our two projects. This web version is where Prince will go to get its content.
-
-The prince script issues a command to the Prince utility. JavaScript is enabled (`--javascript`), and we tell it exactly where to find the list of files (`--input-list`) — just point to the prince-list.txt file. Then we tell it where and what to output (`-o`).
-
-Make sure that the path to the prince-list.txt is correct. For the output directory, I like to output the PDF file into my project's source (into the files folder). Then when I build the web output, the PDF is included and something I can refer to.
-
-{% include note.html content="You might not want to include the PDF in your project files, since you're likely committing the PDF to Github and as a result saving the changes from one PDF version to another with each save." %}
-
-## 6. Add conditions for your new builds in the PDF config file
-
-In the PDF configuration file, there's a section that looks like this:
-
-```
-{% raw %}{% if site.product == "mydoc" %}
-pdf_sidebar: product2_sidebar
-{% endif %}
-```
-
-Point to the sidebar you want here.
-
-What this does is allow the prince-list.txt and toc.html files to iterate through the right sidebar. Otherwise, you would need to create a unique prince-list.txt and toc.html file for each separate PDF output you have.
-
-## 7. Add a download button for the PDF
-
-You can add a download button for your PDF using some Bootstrap button code:
-
-```html
-
-```
-
-Here's what that looks like:
-
-
-
-## JavaScript conflicts
-
-If you have JavaScript on any of your pages, Prince will note errors in Terminal like this:
-
-```
-error: TypeError: value is not an object
-```
-
-However, the PDF will still build.
-
-You need to conditionalize out any JavaScript from your PDF web output before building your PDFs. Make sure that the PDF configuration files have the `output: pdf` property.
-
-Then surround the JavaScript with conditional tags like this:
-
-```
-{% raw %}{% unless site.output == "pdf" %}
-javascript content here ...
-{% endunless %}{% endraw %}
-```
-
-For more detail about using `unless` in conditional logic, see [Conditional logic][mydoc_conditional_logic]. What this code means is "run this code unless this value is the case."
-
-## Overriding Bootstrap Print Styles
-
-The theme relies on Bootstrap's CSS for styling. However, for print media, Bootstrap applies the following style:
-
-```
-@media print{*,:after,:before{color:#000!important;text-shadow:none!important;background:0 0!important;-webkit-box-shadow:none!important;box-shadow:none!important}
-```
-This is minified, but basically the `*` (asterisk) means select all, and applied the color #000 (black). As a result, the Bootstrap style strips out all color from the PDF (for Bootstrap elements).
-
-This is problematic for code snippets that have syntax highlighting. I decided to remove this de-coloring from the print output. I commented out the Bootstrap style:
-
-```
-@media print{*,:after,:before{/*color:#000!important;*/text-shadow:none!important;/*background:0 0!important*/;-webkit-box-shadow:none!important;box-shadow:none!important}
-```
-
-If you update Bootrap, make sure you make this edit. (Sorry, admittedly I couldn't figure out how to simply overwrite the `*` selector with a later style.)
-
-I did, however, remove the color from the alerts and lighten the background shading for `pre` elements. The printstyles.css has this setting.
-
-{% include links.html %}
diff --git a/pages/mydoc/mydoc_git_collaboration.md b/pages/mydoc/mydoc_git_collaboration.md
deleted file mode 100644
index ae0e511b4..000000000
--- a/pages/mydoc/mydoc_git_collaboration.md
+++ /dev/null
@@ -1,185 +0,0 @@
----
-title: Git notes and tips
-summary: "If you're interacting with your team using Git, the notes and tips will help you collaborate efficiently."
-tags: collaboration
-keywords: git, github, collaboration, interaction, file sharing, push
-published: false
-sidebar: mydoc_sidebar
-permalink: mydoc_git_collaboration.html
-folder: mydoc
----
-
-
-hg fetch does a pull and update at the same time
-you're prompted about any conflicts
-you fix them. then you do this:
-
-
-hg pull -u (i think this is pull and then update)
-
-$ hg [COMMAND] [ARGUMENTS]
-
-hg init
-hg add
-hg log
-hg diff
-hg revert
-hg remove
-hg update
-You have seen that it is possible to switch revision using hg update.
-clone
-
-commit
-
-The first feature of the diff command is to show the differences between the last revision of a file (the state at the last commit command) and the current version. It can also show the differences between any two specified revisions. For example, on apache2.conf, the diff command can be used as follows:
-$ hg diff -r 1 -r 2 apache2.conf
-
-To print each line of a file with the revision at which the line was created (and with the --user option, we come to know who committed this revision), type:
-$ hg annotate [FILE] or $ hg blame [FILE]
-
-To search for a pattern in version controlled files, use hg grep; it will search this pattern in every version of the file and it will print the first one in which it appears, such as hg annotate. For example:
-$ hg grep new apache2.conf
-
-You can also print the content of a file at a given revision even without changing the current working directory using hg cat -r REVISION.
-
-Whenever changes have been committed but not yet pushed, the outgoing command lists all the changesets that are present in the current repository but not yet found in the destination (the ones that are candidates to be pushed), whereas the incoming command shows you the changesets that are found in the source repository but have not been pulled yet. So here, if you use the outgoing command, you will see
-
-push
-pull
-fetch
-merge
-resolve --mark
-
-As you can see, you have added John's change to your repository because hg log is listing it. But it is not yet present in your working copy; you need to update the working directory to the tip revision, which is the default of the update command, when no revision is passed as argument:
-
-You can now see John's change in the working directory. If some files had been modified, either committed or not, the modifications would have been seamlessly merged with that of John's. If there was a conflict, Mercurial would have told us.
-
-hg pull --update or -u: This option combines both the pull and the update commands, not only pulling new changesets into the local repository, but also updating the working directory to the head of these new changes.
-
-| annotate, blame | show changeset information by line for each file |
-| diff | diff repository (or selected files) |
-| forget {filename} | forget the specified files on the next commit |
-
-
-hg fetch. This extension acts as a combination of hg pull -u, hg merge and hg commit. It begins by pulling changes from another repository into the current repository. If it finds that the changes added a new head to the repository, it updates to the new head, begins a merge, then (if the merge succeeded) commits the result of the merge with an automatically-generated commit message. If no new heads were added, it updates the working directory to the new tip changeset.
-
-
-
-i like
-
-hg fetch does a pull and update at the same time
-you're prompted about any conflicts
-you fix them. then you do this: hg resolve --mark
-
-
-hg pull -u (i think this is pull and then update)
-
-$ hg [COMMAND] [ARGUMENTS]
-
-hg init
-hg add
-hg log
-hg diff
-hg revert
-hg remove
-hg update
-You have seen that it is possible to switch revision using hg update.
-clone
-addremove, which allows you to automatically add all new files and remove (from version control) files that have been deleted.
-log
-commit
-
-The first feature of the diff command is to show the differences between the last revision of a file (the state at the last commit command) and the current version. It can also show the differences between any two specified revisions. For example, on apache2.conf, the diff command can be used as follows:
-$ hg diff -r 1 -r 2 apache2.conf
-
-To print each line of a file with the revision at which the line was created (and with the --user option, we come to know who committed this revision), type:
-$ hg annotate [FILE] or $ hg blame [FILE]
-
-To search for a pattern in version controlled files, use hg grep; it will search this pattern in every version of the file and it will print the first one in which it appears, such as hg annotate. For example:
-$ hg grep new apache2.conf
-
-You can also print the content of a file at a given revision even without changing the current working directory using hg cat -r REVISION.
-
-Whenever changes have been committed but not yet pushed, the outgoing command lists all the changesets that are present in the current repository but not yet found in the destination (the ones that are candidates to be pushed), whereas the incoming command shows you the changesets that are found in the source repository but have not been pulled yet. So here, if you use the outgoing command, you will see
-
-push
-pull
-fetch
-merge
-resolve --mark
-
-As you can see, you have added John's change to your repository because hg log is listing it. But it is not yet present in your working copy; you need to update the working directory to the tip revision, which is the default of the update command, when no revision is passed as argument:
-
-You can now see John's change in the working directory. If some files had been modified, either committed or not, the modifications would have been seamlessly merged with that of John's. If there was a conflict, Mercurial would have told us.
-
-hg pull --update or -u: This option combines both the pull and the update commands, not only pulling new changesets into the local repository, but also updating the working directory to the head of these new changes.
-
-Bookmarks are tags that move forward automatically to subsequent changes, leaving no mark on the changesets that previously had that bookmark pointing toward them. Named branches, on the other hand, are indelible marks that are part of a changeset. Multiple heads can be on the same branch, but only one head at a time can be pointed to by the same bookmark. Named branches are pushed/pulled from repo to repo, and bookmarks don't travel.
-
-The default branch name in Mercurial is “default”.
-
-The slowest, safest way to create a branch with Mercurial is to make a new clone of the repository. this is really fascinating -- a clone is merely a branch.
-
-Discarding a branch you don’t want any more is very easy with cloned branches. It’s as simple as rm -rf test-project-feature-branch. There’s no need to mess around with editing repository history, you just delete the damn thing.
-
-The next way to branch is to use a bookmark. For example:
-
-$ cd ~/src/test-project
-$ hg bookmark main
-$ hg bookmark feature
-Now you’ve got two bookmarks (essentially a tag) for your two branches at the current changeset.
-
-To switch to one of these branches you can use hg update feature to update to the tip changeset of that branch and mark yourself as working on that branch. When you commit, it will move the bookmark to the newly created changeset.
-
-
-## Git
-HEAD is a reference to the last commit in the current checked out branch.
-
-This is a good tutorial: https://www.digitalocean.com/community/tutorials/how-to-use-git-branches.
-
-
-## Branching
-
-| Commands | Description |
-|------|-------|
-| List all branches | `git branch a` (the * indicates the branch you're on) |
-| Create new branch | `git -b branchname` or `git branch branchname` |
-| Checkout a branch | `git checkout branchname` |
-| Create new branch and checkout at the same time| `git checkout -b branchname` |
-| Merge into current branch | First go into the branch you want to merge changes into. Then do `git merge branchname`. For example, to merge branch b into branch master, first checkout branch master: `git checkout a`. Now merge b into master: `git merge b`.|
-
-git lg
-
-git checkout master
-git merge search | git merge --no-ff search
-
-the latter (--no-ff) keeps the additional information that these commits were made on a branch.
-then type a commit message (:wq)
-git branch -d search
-
-git add . (works same as add --all)
-git commit am "my commit message" (this performs both adding and commit message at same time)
-
-with merge conflicts:
-
-git status (shows you all the files that can't be added due to merge conflicts)
-fix the conflicts
-then git add . (tells git you fixed the conflicts)
-then git status
-git commit
-
-From the interface, you can also create a pull request to merge all of the changes from a specific branch into another branch.
-
-
-
-## General commands
-
-| Commands | Description |
-|------|-------|
-| start tracking files | `git add` |
-| see what has changed since last commit | `git diff` |
-| commit changes | `git commit` |
-| | |
-
-
-{% include links.html %}
diff --git a/pages/mydoc/mydoc_glossary.md b/pages/mydoc/mydoc_glossary.md
deleted file mode 100644
index 264fed782..000000000
--- a/pages/mydoc/mydoc_glossary.md
+++ /dev/null
@@ -1,111 +0,0 @@
----
-title: Glossary layout
-tags: [formatting, special_layouts]
-keywords: definitions, glossaries, terms, style guide
-last_updated: July 3, 2016
-summary: "Your glossary page can take advantage of definitions stored in a data file. This gives you the ability to reuse the same definition in multiple places. Additionally, you can use Bootstrap classes to arrange your definition list horizontally."
-sidebar: mydoc_sidebar
-permalink: mydoc_glossary.html
-toc: false
-folder: mydoc
----
-
-
-You can create a glossary for your content. First create your glossary items in a data file such as glossary.yml.
-
-Then create a page and use definition list formatting, like this:
-
-fractious
-: {{site.data.glossary.fractious}}
-
-gratuitous
-: {{site.data.glossary.gratuitous}}
-
-haughty
-: {{site.data.glossary.haughty}}
-
-gratuitous
-: {{site.data.glossary.gratuitous}}
-
-impertinent
-: {{site.data.glossary.intrepid}}
-
-Here's the code:
-
-```
-{% raw %}fractious
-: {{site.data.glossary.fractious}}
-
-gratuitous
-: {{site.data.glossary.gratuitous}}
-
-haughty
-: {{site.data.glossary.haughty}}
-
-gratuitous
-: {{site.data.glossary.gratuitous}}
-
-impertinent
-: {{site.data.glossary.intrepid}}{% endraw %}
-```
-
-The glossary works well as a link in the top navigation bar.
-
-## Horizontally styled definiton lists
-
-You can also change the definition list (`dl`) class to `dl-horizontal`. This is a Bootstrap specific class. If you do, the styling looks like this:
-
-
-
-Is this really an API? Well, sort of. The help content is pushed out into a JSON file that other websites and applications can easily consume. The endpoints don't deliver different data based on parameters added to a URL. But the overall concept is similar to an API: you have a client requesting resources from a server.
-
-Note that in this scenario, the help is openly accessible on the web. If you have a private system, it's more complicated.
-
-To deliver help this way using Jekyll, follow the steps in each of the sections below.
-
-## 1. Create a "collection" for the help content
-
-A collection is another content type that extends Jekyll beyond the use of pages and posts. Call the collection "tooltips."
-
-Add the following information to your configuration file to declare your collection:
-
-```
-collections:
- tooltips:
- output: false
-```
-
-In your Jekyll project's root directory, create a new folder called "_tooltips" and put every page that you want to be part of that tooltips collection inside that folder.
-
-In Jekyll, folders that begin with an underscore ("_") aren't included in the output. However, in the collection information that you add to your configuration file, if you change `output` to `true`, the tooltips folder will appear in the output, and each page inside tooltips will be generated. You most likely don't want this for tooltips (you just want the JSON file), so make the `output` setting `false`.
-
-## 2. Create tooltip definitions in a YAML file
-
-Inside the \_data folder, create a YAML file called something like definitions.yml. Add the definitions for each of your tooltips here like this:
-
-```yaml
-basketball: "Basketball is a sport involving two teams of five players each competing to put a ball through a small circular rim 10 feet above the ground. Basketball requires players to be in top physical condition, since they spend most of the game running back and forth along a 94-foot-long floor."
-```
-
-The definition of basketball is stored this data file so that you can re-use it in other parts of the help as well. You'll likely want the definition to appear not only in the tooltip in the UI, but also in the regular documentation as well.
-
-## 3. Create pages in your collection
-
-Create pages inside your new tooltips collection (that is, inside the \_tooltips folder). Each page needs to have a unique `id` in the frontmatter as well as a `product`. Then reference the definition you created in the definitions.yml file.
-
-Here's an example:
-
-```yaml
-{% raw %}
----
-doc_id: basketball
-product: mydoc
----
-
-{{site.data.definitions.basketball}}{% endraw %}
-```
-
-(Note: Avoid using `id`, as it seems to generate out as `/tooltips/basketball` instead of just `basketball.)
-
-You need to create a separate file for each tooltip you want to deliver.
-
-The product attribute is required in the frontmatter to distinguish the tooltips produced here from the tooltips for other products in the same \_tooltips folder. When creating the JSON file, Jekyll will iterate through all the pages inside \_tooltips, regardless of any subfolders included here.
-
-## 4. Create a JSON file that loops through your collection pages
-
-Now it's time to create a JSON file with Liquid code that iterates through our tooltip collection and grabs the information from each tooltip file.
-
-Inside your project's pages directory (e.g., mydoc), add a file called "tooltips.json." (You can use whatever name you want.) Add the following to your JSON file:
-
-{% raw %}
-```liquid
----
-layout: null
-search: exclude
----
-
-{
-"entries":
-[
-{% for page in site.tooltips %}
-{
-"doc_id": "{{ page.doc_id }}",
-"body": "{{ page.content | strip_newlines | replace: '\', '\\\\' | replace: '"', '\\"' }}"
-} {% unless forloop.last %},{% endunless %}
-{% endfor %}
-]
-}
-
-```
-{% endraw %}
-
-This code will loop through all pages in the tooltips collection and insert the `id` and `body` into key-value pairs for the JSON code. Here's an example of what that looks like after it's processed by Jekyll in the site build:
-
-```json
-{
- "entries": [
- {
- "doc_id": "baseball",
- "body": "{{site.data.definitions.baseball}}"
- },
- {
- "doc_id": "basketball",
- "body": "{{site.data.definitions.basketball}}"
- },
- {
- "doc_id": "football",
- "body": "{{site.data.definitions.football}}"
- },
- {
- "doc_id": "soccer",
- "body": "{{site.data.definitions.soccer}}"
- }
- ]
-}
-```
-
-You can also view the same JSON file here: tooltips.json.
-
-You can add different fields depending on how you want the JSON to be structured. Here we just have to fields: `doc_id` and `body`. And the JSON is looking just in the tooltips collection that we created.
-
-{% include tip.html content="Check out [Google's style guide](https://google.github.io/styleguide/jsoncstyleguide.xml) for JSON. These best practices can help you keep your JSON file valid." %}
-
-Note that you can create different JSON files that specialize in different content. For example, suppose you have some getting started information. You could put that into a different JSON file. Using the same structure, you might add an `if` tag that checks whether the page has frontmatter that says `type: getting_started` or something. Or you could put the content into separate collection entirely (different from tooltips).
-
-By chunking up your JSON files, you can provide a quicker lookup. (I'm not sure how big the JSON file can be before you experience any latency with the jQuery lookup.)
-
-## 5. Build your site and look for the JSON file
-
-When you build your site, Jekyll will iterate through every page in your _tooltips folder and put the page id and body into this format. In the output, look for the JSON file in the tooltips.json file. You'll see that Jekyll has populated it with content. This is because of the triple hyphen lines in the JSON file — this instructs Jekyll to process the file.
-
-## 6. Allow CORS access to your help if stored on a remote server
-
-You can simply deliver the JSON file to devs to add to the project. But if you have the option, it's best to keep the JSON file stored in your own help system. Assuming you have the ability to update your content on the fly, this will give you completely control over the tooltips without being tied to a specific release window.
-
-When people make calls to your site *from other domains*, you must allow them access to get the content. To do this, you have to enable something called CORS (cross origin resource sharing) within the server where your help resides.
-
-In other words, people are going to be executing calls to reach into your site and grab your content. Just like the door on your house, you have to unlock it so people can get in. Enabling CORS is unlocking it.
-
-How you enable CORS depends on the type of server.
-
-If your server setup allows htaccess files to override general server permissions, create an .htaccess file and add the following:
-
-```
-Header set Access-Control-Allow-Origin "*"
-```
-
-Store this in the same directory as your project. This is what I've done in a directory on my web host (bluehost.com). Inside http://idratherassets.com/wp-content/apidemos/, I uploaded a file called ".htaccess" with the preceding code.
-
-After I uploaded it, I renamed it to .htaccess, right-clicked the file and set the permissions to 774.
-
-To test whether your server permissions are set correctly, open a terminal and run the following curl command pointing to your tooltips.json file:
-
-```
-curl -I http://idratherassets.com/wp-content/apidemos/tooltips.json
-```
-
-The `-I` command tells cURL to return the request header only.
-
-If the server permissions are set correctly, you should see the following line somewhere in the response:
-
-```xml
-Access-Control-Allow-Origin: *
-```
-
-If you don't see this response, CORS isn't allowed for the file.
-
-If you have an AWS S3 bucket, you can supposedly add a CORS configuration to the bucket permissions. Log into AWS S3 and click your bucket. On the right, in the Permissions section, click **Add CORS Configuration**. In that space, add the following policy:
-
-```xml
-Basketball
-``` - -Notice that I just have `id="basketball"` added to this popover element. Developers merely need to add a unique ID to each tooltip they want to pull in the help content. Either you tell developers the unique ID they should add, or ask them what IDs they added (or just tell them to use an ID that matches the field's name). - -In order to use jQuery and Bootstrap, you'll need to add the appropriate references in the head tags of your page: - -```js - - - - - -``` - -Again, see the Tooltip Demo for a demo of the full code. - -Note that even though you reference a Bootstrap JS script, Bootstrap's popovers require you to initialize them using the above code as well — they aren't turned on by default. - -View the source code of the tooltip demo for the full comments. - -## 8. Create easy links to embed the help in your help site - -You might also want to insert the same content into different parts of your help site. For example, if you have tooltips providing definitions for fields, you'll probably want to create a page in your help that lists those same definitions. - -You could use the same method developers use to pull help content into their applications. But it will probably be easier to simply use Jekyll's tags for doing it. - -Here's how you would reuse the content: - - -```html -{% raw %}| Sport | -Comments | -
|---|---|
| Basketball | -{{site.data.definitions.basketball}} | -
| Baseball | -{{site.data.definitions.baseball}} | -
| Football | -{{site.data.definitions.football}} | -
| Soccer | -{{site.data.definitions.soccer}} | -
| Sport | -Comments | -
|---|---|
| Basketball | -{{site.data.definitions.basketball}} | -
| Baseball | -{{site.data.definitions.baseball}} | -
| Football | -{{site.data.definitions.football}} | -
| Soccer | -{{site.data.definitions.soccer}} | -
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam vel sollicitudin felis. Sed eu arcu sed ipsum semper luctus eu a tortor. Suspendisse id leo eu metus laoreet varius. Mauris consequat accumsan ex, a iaculis metus fermentum a. Praesent sit amet fermentum leo. Aliquam feugiat, nibh in u ltrices mattis, felis ipsum venenatis metus, vel vehicula libero mauris a enim. Sed placerat est ac lectus vestibulum tempor. Quisque ut condimentum massa. Proin venenatis leo id urna cursus blandit. Vivamus sit amet hendrerit metus.about
Vel vehicula libero mauris a enim. Sed placerat est ac lectus vestibulum tempor. Quisque ut condimentum massa. Proin venenatis leo id urna cursus blandit. Vivamus sit amet hendrerit metus.
-Praesent sit amet fermentum leo....
-Lorem ipsum ...
Vel vehicula ....
-{% assign series_pages = site.tags.series_acme %} - {% for p in pages %} - {% if p.series == "ACME series" %} - {% assign nextTopic = page.weight | plus: "1" %} - {% if p.weight == nextTopic %} - - {% endif %} - {% endif %} - {% endfor %} -
-``` -{% endraw %} - -Change "acme" to the name of your series. - -Save this in your \_includes/custom/mydoc folder as series\_acme\_next.html. - -## 3. Add the correct frontmatter to each of your series pages - -Now add the following frontmatter to each page in the series: - -```json -series: "ACME series" -weight: 1.0 -``` - -With weights, Jekyll will treat 10 as coming after 1. If you have more than 10 items, consider changing `plus: "1.0"` to `plus: "0.1"`. - -Additionally, if your page names are prefaced with numbers, such as "1. Download the code," then the {% raw %}`{{p.weight}}`{% endraw %} will create a duplicate number. In that case, just remove the {% raw %}`{{p.weight}}`{% endraw %} from both code samples here. - -## 4. Add links to the series button and next button on each page. - -On each series page, add a link to the series button at the top and a link to the next button at the bottom. - -{% raw %} -```liquid - - -{% include custom/series_acme.html %} - - - -{% include custom/series_acme_next.html %} -``` -{% endraw %} - -## Changing the series drop-down color - -The Bootstrap menu uses the `primary` class for styling. If you change this class in your theme, the Bootstrap menu should automatically change color as well. You can also just use another Bootstrap class in your button code. Instead of `btn-primary`, use `btn-info` or `btn-warning`. See [Labels][mydoc_labels] for more Bootstrap button classes. - -## Using a collection with your series - -Instead of copying and pasting the button includes on each of your series, you could also create a collection and define a layout for the collection that has the include code. For more information on creating collections, see [Collections][mydoc_collections] for more details. - -{% include links.html %} diff --git a/pages/mydoc/mydoc_seriesdemo1.md b/pages/mydoc/mydoc_seriesdemo1.md deleted file mode 100644 index 5a4ec168c..000000000 --- a/pages/mydoc/mydoc_seriesdemo1.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Series demo 1 -summary: "This is the first post in the series." -series: "ACME series" -weight: 1 -last_updated: July 3, 2016 -sidebar: mydoc_sidebar -permalink: mydoc_seriesdemo1.html -folder: mydoc ---- - -{% include custom/series_acme_next.html %} - -This is the first post in the series. - -Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam vel sollicitudin felis. Sed eu arcu sed ipsum semper luctus eu a tortor. Suspendisse id leo eu metus laoreet varius. Mauris consequat accumsan ex, a iaculis metus fermentum a. Praesent sit amet fermentum leo. Aliquam feugiat, nibh in ultrices mattis, felis ipsum venenatis metus, vel vehicula libero mauris a enim. Sed placerat est ac lectus vestibulum tempor. Quisque ut condimentum massa. Proin venenatis leo id urna cursus blandit. Vivamus sit amet hendrerit metus. - -Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam vel sollicitudin felis. Sed eu arcu sed ipsum semper luctus eu a tortor. Suspendisse id leo eu metus laoreet varius. Mauris consequat accumsan ex, a iaculis metus fermentum a. Praesent sit amet fermentum leo. Aliquam feugiat, nibh in ultrices mattis, felis ipsum venenatis metus, vel vehicula libero mauris a enim. Sed placerat est ac lectus vestibulum tempor. Quisque ut condimentum massa. Proin venenatis leo id urna cursus blandit. Vivamus sit amet hendrerit metus. - - - -{% include links.html %} diff --git a/pages/mydoc/mydoc_seriesdemo2.md b/pages/mydoc/mydoc_seriesdemo2.md deleted file mode 100644 index 048e73549..000000000 --- a/pages/mydoc/mydoc_seriesdemo2.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Series demo 2 -summary: "This is the second post in the series." -series: "ACME series" -weight: 2 -last_updated: July 3, 2016 -sidebar: mydoc_sidebar -permalink: mydoc_seriesdemo2.html -folder: mydoc ---- - - -{% include custom/series_acme_next.html %} - -This is the second post in the series. - -Aliquam feugiat, nibh in ultrices mattis, felis ipsum venenatis metus, vel vehicula libero mauris a enim. Sed placerat est ac lectus vestibulum tempor. Quisque ut condimentum massa. Proin venenatis leo id urna cursus blandit. Vivamus sit amet hendrerit metus. - -Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam vel sollicitudin felis. Sed eu arcu sed ipsum semper luctus eu a tortor. Suspendisse id leo eu metus laoreet varius. Mauris consequat accumsan ex, a iaculis metus fermentum a. Praesent sit amet fermentum leo. Aliquam feugiat, nibh in ultrices mattis, felis ipsum venenatis metus, vel vehicula libero mauris a enim. Sed placerat est ac lectus vestibulum tempor. Quisque ut condimentum massa. Proin venenatis leo id urna cursus blandit. Vivamus sit amet hendrerit metus. - -Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam vel sollicitudin felis. Sed eu arcu sed ipsum semper luctus eu a tortor. Suspendisse id leo eu metus laoreet varius. Mauris consequat accumsan ex, a iaculis metus fermentum a. Praesent sit amet fermentum leo. - - -{% include links.html %} diff --git a/pages/mydoc/mydoc_seriesdemo3.md b/pages/mydoc/mydoc_seriesdemo3.md deleted file mode 100644 index dcf2ddbc0..000000000 --- a/pages/mydoc/mydoc_seriesdemo3.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Series demo 3 -last_updated: May 17, 2016 -summary: "This is the third post in the series." -series: "ACME series" -weight: 3 -last_updated: July 3, 2016 -sidebar: mydoc_sidebar -permalink: mydoc_seriesdemo3.html -folder: mydoc ---- - -{% include custom/series_acme_next.html %} - -This is the third post in the series. - -Mauris consequat accumsan ex, a iaculis metus fermentum a. Praesent sit amet fermentum leo. Aliquam feugiat, nibh in ultrices mattis, felis ipsum venenatis metus, vel vehicula libero mauris a enim. Sed placerat est ac lectus vestibulum tempor. Quisque ut condimentum massa. Proin venenatis leo id urna cursus blandit. Vivamus sit amet hendrerit metus. - -Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam vel sollicitudin felis. Sed eu arcu sed ipsum semper luctus eu a tortor. Suspendisse id leo eu metus laoreet varius. - -Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam vel sollicitudin felis. Sed eu arcu sed ipsum semper luctus eu a tortor. Suspendisse id leo eu metus laoreet varius. Mauris consequat accumsan ex, a iaculis metus fermentum a. Praesent sit amet fermentum leo. Aliquam feugiat, nibh in ultrices mattis, felis ipsum venenatis metus, vel vehicula libero mauris a enim. Sed placerat est ac lectus vestibulum tempor. Quisque ut condimentum massa. Proin venenatis leo id urna cursus blandit. Vivamus sit amet hendrerit metus. - - -{% include links.html %} diff --git a/pages/mydoc/mydoc_seriesdemo4.md b/pages/mydoc/mydoc_seriesdemo4.md deleted file mode 100644 index 57ea639a8..000000000 --- a/pages/mydoc/mydoc_seriesdemo4.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Series demo 4 -summary: "This is the fourth post in the series." -series: "ACME series" -weight: 4 -last_updated: July 3, 2016 -sidebar: mydoc_sidebar -permalink: mydoc_seriesdemo4.html -folder: mydoc ---- - - -{% include custom/series_acme_next.html %} - -This is the fourth post in the series. - -Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam vel sollicitudin felis. Sed eu arcu sed ipsum semper luctus eu a tortor. Suspendisse id leo eu metus laoreet varius. Mauris consequat accumsan ex, a iaculis metus fermentum a. Praesent sit amet fermentum leo. Aliquam feugiat, nibh in ultrices mattis, felis ipsum venenatis metus, vel vehicula libero mauris a enim. Sed placerat est ac lectus vestibulum tempor. Quisque ut condimentum massa. Proin venenatis leo id urna cursus blandit. Vivamus sit amet hendrerit metus. - - -Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam vel sollicitudin felis. Sed eu arcu sed ipsum semper luctus eu a tortor. Suspendisse id leo eu metus laoreet varius. Mauris consequat accumsan ex, a iaculis metus fermentum a. Praesent sit amet fermentum leo. Aliquam feugiat, nibh in ultrices mattis, felis ipsum venenatis metus, vel vehicula libero mauris a enim. Sed placerat est ac lectus vestibulum tempor. Quisque ut condimentum massa. Proin venenatis leo id urna cursus blandit. Vivamus sit amet hendrerit metus. - -Mauris consequat accumsan ex, a iaculis metus fermentum a. Praesent sit amet fermentum leo. Aliquam feugiat, nibh in ultrices mattis, felis ipsum venenatis metus, vel vehicula libero mauris a enim. Sed placerat est ac lectus vestibulum tempor. Quisque ut condimentum massa. Proin venenatis leo id urna cursus blandit. Vivamus sit amet hendrerit metus. - -Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam vel sollicitudin felis. Sed eu arcu sed ipsum semper luctus eu a tortor. Suspendisse id leo eu metus laoreet varius. - -{% include links.html %} diff --git a/pages/mydoc/mydoc_shuffle.html b/pages/mydoc/mydoc_shuffle.html deleted file mode 100644 index 398703746..000000000 --- a/pages/mydoc/mydoc_shuffle.html +++ /dev/null @@ -1,167 +0,0 @@ ---- -title: Shuffle layout -tags: [special_layouts] -last_updated: November 30, 2015 -keywords: shuffle, card layout, dynamic grid, doc portal, support portal -summary: "This layout shows an example of a knowledge-base style navigation system, where there is no hierarchy, just groups of pages that have certain tags." -permalink: mydoc_shuffle.html -sidebar: mydoc_sidebar -folder: mydoc ---- - - - -{% if site.output == "pdf" %} -{{site.data.alerts.note}} The content on this page doesn't display well on PDF, but I included it anyway so you could see the problems this layout poses if you're including it in PDF. {{site.data.alerts.end}} -{% endif %} - -{% unless site.output == "pdf" %} - - -{% endunless %} - - - -
-```java
-import java.util.Scanner;
-
-public class ScannerAndKeyboard
-{
-
- public static void main(String[] args)
- { Scanner s = new Scanner(System.in);
- System.out.print( "Enter your name: " );
- String name = s.nextLine();
- System.out.println( "Hello " + name + "!" );
- }
-}
-```
-
-
-This looks as follows:
-
-```java
-import java.util.Scanner;
-
-public class ScannerAndKeyboard
-{
-
- public static void main(String[] args)
- { Scanner s = new Scanner(System.in);
- System.out.print( "Enter your name: " );
- String name = s.nextLine();
- System.out.println( "Hello " + name + "!" );
- }
-}
-```
-
-Fenced code blocks require a blank line before and after.
-
-If you're using an HTML file, you can also use the `highlight` command with Liquid markup.
-
-
-{% raw %}{% highlight java %}
-import java.util.Scanner;
-
-public class ScannerAndKeyboard
-{
-
- public static void main(String[] args)
- { Scanner s = new Scanner(System.in);
- System.out.print( "Enter your name: " );
- String name = s.nextLine();
- System.out.println( "Hello " + name + "!" );
- }
-}
-{% endhighlight %}{% endraw %}
-
-
-Result:
-
-{% highlight java %}
-import java.util.Scanner;
-
-public class ScannerAndKeyboard
-{
-
- public static void main(String[] args)
- { Scanner s = new Scanner(System.in);
- System.out.print( "Enter your name: " );
- String name = s.nextLine();
- System.out.println( "Hello " + name + "!" );
- }
-}
-{% endhighlight %}
-
-The theme has syntax highlighting specified in the configuration file as follows:
-
-```
-highlighter: rouge
-```
-
-The syntax highlighting is done via the css/syntax.css file.
-
-## Available lexers
-
-The keywords you must add to specify the highlighting (in the previous example, `ruby`) are called "lexers." You can search for "lexers." Here are some common ones I use:
-
-* js
-* html
-* yaml
-* css
-* json
-* php
-* java
-* cpp
-* dotnet
-* xml
-* http
-
-{% include links.html %}
diff --git a/pages/mydoc/mydoc_tables.md b/pages/mydoc/mydoc_tables.md
deleted file mode 100644
index 952a0784b..000000000
--- a/pages/mydoc/mydoc_tables.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: Tables
-tags: [formatting]
-keywords: datatables, tables, grids, markdown, multimarkdown, jquery plugins
-last_updated: July 16, 2016
-datatable: true
-summary: "You can format tables using either multimarkdown syntax or HTML. You can also use jQuery datatables (a plugin) if you need more robust tables."
-sidebar: mydoc_sidebar
-permalink: mydoc_tables.html
-folder: mydoc
----
-
-## Multimarkdown Tables
-
-You can use Multimarkdown syntax for tables. The following shows a sample:
-
-```
-| Priority apples | Second priority | Third priority |
-|-------|--------|---------|
-| ambrosia | gala | red delicious |
-| pink lady | jazz | macintosh |
-| honeycrisp | granny smith | fuji |
-```
-
-**Result:**
-
-| Priority apples | Second priority | Third priority |
-|-------|--------|---------|
-| ambrosia | gala | red delicious |
-| pink lady | jazz | macintosh |
-| honeycrisp | granny smith | fuji |
-
-{% include note.html content="You can't use block level tags (paragraphs or lists) inside Markdown tables, so if you need separate paragraphs inside a cell, use `| Field | -Description | -
|---|---|
| First column **fields** | -Some descriptive text. This is a markdown link to [Google](http://google.com). Or see [some link][mydoc_tags]. | -
| Second column **fields** | -Some more descriptive text. - | -
| Field | -Description | -
|---|---|
| First column **fields** | -Some descriptive text. This is a markdown link to [Google](http://google.com). Or see [some link][mydoc_tags]. | -
| Second column **fields** | -Some more descriptive text. - | -