Conforming to principles of web of data [1], all resources in MICA platform are identified using HTTP URIs (Uniform Resource Identifiers) [2][3], whether they are vocabulary elements (defined in ontologies) or documents (factsheet, flowsheet, data sources...) managed by the platform. Through the resource URIs (for example a factsheet) it's possible to access various representations of it: a pdf document, a docx document,a rdf representation of it... For this reason it's important to choose URIs for MICA resources in a domain whose HTTP server can be configured to either:
Since MICA project involves various partners whose HTTP servers are in different domains (brgm.fr for BRGM, geus.dk for GEUS, imag.fr for LIG ...), we opted for a solution based on Persistent URLs [4] (PURLs) whose resolution is supported by a third party. Proceeding in this way allows to define URIs that will not change wherever the resources are hosted (LIG, BRGM ...).
PURLs are simply adresses (URLs) on the World Wide Web that cause a redirection to another web resource. If the web resource changes it's physical location (and hence URL), a PURL pointing to it can be updating. This modification can be performed transparently to the end-user that always uses the same Web adress (the PURL).
The PURL concept was initially developped at the Online Computer Library Center which operated an HTTP resolver (from 1995 to september 2016) that was reached as http://purl.org. Many popular vocabularies use this service to provide persitent URIs, among them the Dublin Core Meta Data Terms (http://purl.org/dc/terms/).
In 2016, at the start of the MICA project,Whereas the purl.org resolver was still working for resolving existing URIs it was not possible to define new domains for new PURLs. This is the reason why we choosed another PURL service provided by https://w3id.org and to defined a mica domain on it. Proceedng this way, all the URIs cocnerning MICA resources start with the same prefix:
https://w3id.org/mica/
On September 2016,OCLC announced a cooperation with the Internet Archive resulting in the transfer of the resolver service and its administration interface to Internet Archive. This transfer was effective at the begining of 2017 and reenabled the ability manage PURL definitions that had been disabled in the OCLC hosted service for several months.
We evaluated this service in order to investigate whether it was relevant to move the management of Persistent URIs for MICA resources to it. As we found no significant benefit, we felt it was not necessary to make this change.
advantages | disavantages |
a popular service for creating permanent urls on the web. | Requests for information or changes to the service frequently go unanswered. |
had been working for more than 15 years. | The site was designed for the library community and was never intended to be used by the general Web. |
was widely used by the community. | The site is run by a single organization. |
OCLC and the Internet Archive . | impossible to delete a domain. |
advantages | disavantages |
has been adopted by a great part of the community (with more than 10K registered ids) | there is no official commitment from the W3C for maintenance. |
is supported by several companies. | you don’t have a user interface to edit you purls. |
You do so through Github by editing there the .htaccess files. | is a bit geekier, but way more flexible and powerful when doing content negotiation. |
The site is specifically designed for web developers, authors, and data publishers on the general Web. It is not tailored for any specific community. |
You must follow the steps below in order to publish the URI by using the w3id:
For example, I fork the project on my account natetem then the project name is the following https://github.com/natetem/w3id.org.git
git clone https://github.com/natetem/w3id.org.git
Now I have the project on my computer.
In our case the name of project is mica, before creating that folder, be sure that the name of your own project is unique otherwise there will be a conflict.
For further, you can create the sub-folders of your project in order to better organize your project. In our case, we create two sub-folders
In every sub-folders, we create a new file .htaccess. This file contains the rules for negotiation content.
The first part of .htaccess file describe the common rules for every negotiation content.
Options +FollowSymLinks # Turn off MultiViews Options -MultiViews # Directive to ensure *.rdf files served as appropriate content type, # if not present in main apache config AddType application/rdf+xml .rdf AddType text/turtle .ttl RewriteEngine on
the rewrite engine means that the name of our URIs will start with http://w3id.org/mica/ontology/nameXXX for the ontology. but for resource will start with http://w3id.org/mica/resource/nameXXX
The rest of file describe the rules for available type of data format.
#Rewrite rules for MicaModel HTML content from the vocabulary URI if requested RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml) RewriteCond %{HTTP_ACCEPT} text/html [OR] RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR] RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.* RewriteRule ^MicaModel$ http://lig-coin.imag.fr/mica/ontology/MicaModel/MicaModel.html [R=303,NE,L]
RewriteRule for the example above use regular expression for MicaModel, which means that when URI starts with http://w3id.org/mica/ontology/MicaModel it will be redirect to lig-coin server with a local file for model.
Note that we can also use any redirect URLs , it can be application URL or some things else.
# Rewrite rule to serve RDF/XML content from the vocabulary URI if requested RewriteCond %{HTTP_ACCEPT} application/rdf\+xml RewriteRule ^MicaModel$ http://lig-coin.imag.fr/mica/ontology/MicaModel/MicaModel.rdf [R=303,NE,L]
# Rewrite rule to serve RDF/XML content from the vocabulary URI if requested RewriteCond %{HTTP_ACCEPT} text/turtle RewriteRule ^MicaOntology/(.+) http://lig-coin.imag.fr/MICAURI/ontology/data/$1?type=rdf [R=303,NE,L]
When you finish to create the .htaccess file, you commit you change on github.
git add .
git commit -m" add the rules...."
git push
When you changes your URIs and you want to add your changes, you follow the following steps.
URI (Uniform Resource Identifier) are used to uniquely identify the entities used in the MICA project.
In Mica project, we have three forms of entities names according to where they are defined.
The following picture represents the data model used in MICA Project (click here to see MICAModel).
For every class or propertie (attribute or relation), the URI starts with https://w3id.org/mica/ontology/MicaModel#
For the following examples, every resource (class or propertie) will correspond to the URI:
MICAOntology describe the vocabulary (various ontologies or more precisely taxonomies of terms) used in MICA project to annotate the MICA resources. (click here to see MICAOntology). This vocabulary is expressed with the SKOS ontology. For every concept in this vocabulary, its URI starts with https://w3id.org/mica/ontology/MicaOntology/
The following examples give the URIs that identifiy some of the concepts defined in MICAOntology and used in Mica Project.
MICA resources managed by the MICA platform are instances of the MICAModel classAnnotatedResources (FactSheets, DefSheets, DocSheets, FlowSheets, LinkedDataResources, MicaDataResources, WebDocumentResources, Questions) or instances of Agent class (Organization or Person) The URI of a resource starts with the prefix https://w3id.org/mica/resource/.
To avoid ambiguities on resources naming , especially to augment readability of SPARQL queries, we suggest to start the local name of a resource with its type. See the following examples of URIs for of each type of resources used in this project.
Content negotiation allows a user (human or program) to get different representations (in various format) a given resource.
For example, given the URI of the factsheet about Mine closure (https://w3id.org/mica/resource/FactSheetMineClosure) it is possible to obtain its RDF description in a given RDF serialization format (RDF/XML, Turtle or JSON-LD) or as a HTML page. It's also possibe to get a pdf or docx file of the factsheet.
The representation format is defined in the Accept: header of the HTTP request used to dereference the resource URI.
Content negotiation is available for all URIs defined in MICA (https://w3id.org/mica/resource/..., https://w3id.org/mica/ontology/MicaOntology/..., https://w3id.org/mica/ontology/MicaModel#....
In the following examples, we use the the wget or curl command-line tools to download different representations of the factsheet using HTTP requests.
wget --header "Accept: application/rdf+xml" -O FSMineClosure.rdf https://w3id.org/mica/resource/FactSheetMineClosure
curl -LH "Accept: application/rdf+xml" -o FSMineClosure.rdf https://w3id.org/mica/resource/FactSheetMineClosure
As we know the turtle serialization format is the most human readable format.
wget --header "Accept: text/turtle" -O FSMineClosure.ttl https://w3id.org/mica/resource/FactSheetMineClosure
curl -LH "Accept: text/turtle" -o FSMineClosure.ttl https://w3id.org/mica/resource/FactSheetMineClosure
You can also get a representation in Json-LD format by using the following commands:
wget --header "Accept: application/json" -O FSMineClosure.json https://w3id.org/mica/resource/FactSheetMineClosure
curl -LH "Accept: application/json" -o FSMineClosure.json https://w3id.org/mica/resource/FactSheetMineClosure
If you want to download a html file representing the resoruce, you can use the following commands:
wget --header "Accept: text/html" -O FSMineClosure.html https://w3id.org/mica/resource/FactSheetMineClosure
curl -LH "Accept:text/html" -o FSMineClosure.html https://w3id.org/mica/resource/FactSheetMineClosure
If you write directly the resource uri https://w3id.org/mica/resource/FactSheetMineClosure in your browser, this page will be directly displayed in your browser window.