Demo

Please see the included video to see how to use the demo instance. You can also go through the testing scenario seen in the video step by step yourself.

Go to the demo instance

Full testing scenario

In this scenario, we are going to create a specification for Company data as the specification editor. Next, we will imagine that a data producer follows the specification for JSON and provides compliant data. Finally, we are going to show how a data consumer can reuse the specification to load the data from the publisher into a set of various local databases, each with its own data model.

Specification editor

We start as the specification editor role.

  1. Open the Atlas demo instance in a new window, so that you can follow this scenario.
  2. Click the “+” button to create a new project.
  3. Name the project and click the Create button.
  4. We will start with Edit specification
  5. Now, we need to indicate, that our vocabulary source is going to be the EU Core Vocabularies, the vocabularies reused from them, and their supplement.1 We do that by clicking on RDF files in the Vocabulary sources section, providing this list and clicking the Save button:
https://mff-uk.github.io/demo-vocabularies/original/adms.ttl
https://mff-uk.github.io/demo-vocabularies/original/dublin_core_terms.ttl
https://semiceu.github.io/Core-Business-Vocabulary/releases/2.00/voc/core-business-ap.ttl
https://semiceu.github.io/Core-Location-Vocabulary/releases/2.0.1/voc/core-location-ap.ttl
https://www.w3.org/ns/org
https://www.w3.org/ns/regorg
https://mff-uk.github.io/demo-vocabularies/original/skos.rdf
https://schema.org/version/latest/schemaorg-current-https.ttl
https://stirdata.github.io/data-specification/stirdata.ttl
https://mff-uk.github.io/demo-vocabularies/modified/modifications.ttl
  1. Next, we create our desired data structure. Click on the Create data structure tile.
  2. We set the root of the structure using the Set root element button and choosing Legal Entity
  3. Now we add the contents of the Legal Entity root by hovering over the Legal Entity and clicking the “+” button. We want to add
    1. Legal Entity -> Associations -> Identifier
    2. Legal Entity -> Attributes -> legal name
    3. Organization -> Attributes -> foundingDate
    4. Legal Entity -> Associations -> registered address
  4. We click the Confirm (4) button and expand the Legal Entity tree to see the added contents.
  5. The same way as before, we are going to add the following content to Identifier
    1. Identifier -> Attributes -> notation
  6. The same way as before, we are going to add the following content to registered address
    1. Address -> address area
    2. Address -> administrative unit level 1
    3. Address -> administrative unit level 2
    4. Address -> locator designator
    5. Address -> post code
    6. Address -> post name
    7. Address -> thoroughfare
  7. Now, the basic structure is done. However, we need to adjust the technical labels of attributes and associations to be used in technical artifacts such as JSON data and JSON Schema, the multiplicities and the datatypes of the attributes as this information is missing in the vocabulary sources. We do that by using the “edit” button next to the attributes and associations and adjusting as necessary. We can also adjust the order of the attributes by dragging them. The result should look like this:
    1. identifier [1..1]
      1. notation: String [1..1]
    2. legal name: Text [1..1]
    3. founding_date: Date [0..1]
    4. registered_address [0..1]
      1. address_area: Text [0..1]
      2. locator_designator: String [0..1]
      3. post_code: String [0..1]
      4. post_name: Text [0..1]
      5. admin_unit_l1: Text [0..1]
      6. admin_unit_l1: Text [0..1]
      7. thoroughfare: Text [0..1]
  8. Now, Back to specification manager and Go back to Atlas
  9. Go to Generate artifacts, click on Generate .ZIP file. The specification including the technical artifacts is downloaded and can be published on the Web. Go back to Atlas

Data producer

  1. We do not focus on the data producer role in this scenario. We imagine that the data producer finds the data specification and publishes data compliant with the JSON Schema from the specification, producing a JSON-LD file which is also an RDF serialization of the compliant data. We provide a sample containing data about two companies from the Czech Business Registry.

Data consumer

  1. In Atlas with the project for Company data open, click on Import schema in the Data consumer section.
  2. You can see the Schema category containing the loaded specification. Click the Save button.
  3. Go to Data sources and create new JSON-LD store type data source, with custom label and the URL of the sample data file, i.e. https://mff-uk.github.io/atlas-docs/test.json.
  4. Go to Jobs, create a new Import data job, label it and select the created data source.
  5. Run the data import job. Now, the data from the publisher is loaded in the MM-evocat internal data representation.
  6. Now, we are going to decompose the data into two logical models. We start with MongoDB.
    1. In MongoDB, we will store company data and addresses. Make sure there is a database instance you have access to. If there is not any you can always use a free online solution.
    2. Click on Databases, Create new. Select type MongoDB, fill all other necessary information and click on Add.
    3. Click on Logical Models, Create new, MongoDB database, custom label, e.g. “Mongo Company Data”.
    4. Click on the created logical model and Create new under Mappings.
    5. Click on the node Legal Entity, Confirm. Note that the current mapping of the Schema category to the MongoDB data model can be seen on the right-hand side. Do not click on “Finish mapping” until we are done with creating it.
    6. Click on the “+” button in the legal_entity on the right hand side to add a property.2 Click on the notation node in the graph at the end of the path Legal Entity -> Identifier -> notation.
    7. Click Next, select Static, click Next, rename to _id and Finish.
    8. In the same way, add legalName and foundingDate.
    9. When adding Address, note that this needs to be added as a Complex type of property, as it will have subproperties.
    10. Finally, we are going to add the properties of the address and click on Finish mapping.
  7. Now, we add a second model for PostgreSQL.
    1. Click on Databases, Create new. Select type PostgreSQL, fill the connection details and click on Add.
    2. Click on Logical Models, Create new, PostgreSQL database, custom label, e.g. “SQL Addresses”.
    3. Click on the created logical model and Create new under Mappings
    4. We select Address as a root and add the address attributes (their _value parts) to the mapping and Finish mapping.
  8. Click on Jobs and create a Category to Model job with the MongoDB model selected. Run the job to store the data from the MM-evocat internal representation to MongoDB.
  9. Do the same for the PostgreSQL model.
  10. By now, both databases should have been already populated with the data. If you want to see the statements that were used to do so, click on Models and select the model you want to view.

  1. Note that the links point to the original vocabularies whenever they support CORS, which is necessary for Dataspecer to be able to access them. The vocabularies that do not support CORS were cached in our GitHub repository↩︎

  2. This is a bit similar to what we did as a Specification editor in Dataspecer. Re-using the data structure from there for this step is our future work. ↩︎