Since most Semantic Web data come from relational databases, several proposals exist, aimed at producing RDF data from relational data stored in different repositories. Two problems arise here. On the one hand, data have to be translated (mapped) from the relational format to the RDF data model. On the other hand, one can choose between storing RDF data in a data store or producing RDF triples on-the-fly. Several proposals and standards have been developed for this. The most relevant of them are discussed below.
Section 3.1 studies the R2RML mapping language, the standard language chosen for this project, while
Section 3.2 comments on other proposals and compares them against R2RML.
Section 3.3 and
Section 3.4 present the XML and spatial extensions to R2RML developed for the project.
3.1. The R2RML Mapping Language
The W3C standard for mapping relational to RDF data, denoted R2RML [
26], is a customized mapping whose result is a collection of RDF triples in Turtle syntax that represents all or a portion of a relational database. The main object of an R2RML mapping is the “triples map”. Each triples’ map yields a collection of triples, and it is composed of a “logical table”, a “subject map”, and zero or more “predicate object maps”. A logical table can be either a table name (defined using predicate
rr:tableName) or an SQL query (defined using predicate
rr:sqlQuery). A predicate object map is composed of a predicate map and an object map. Subject maps, predicate maps, and predicate object maps can be constants (using predicate
rr:constant), column-based maps (using predicate
rr:column), or template-based maps (predicate
rr:template).
The example in Listing 1 depicts the mapping into RDF of a table called Professor. This table contains attributes id, name, department, and gender. For this mapping, the R2RML language is used. The triples representing a given instance of this table are produced applying the mapping shown in the figure. For example, applying the mapping to the tuple <1,Professor, A. Vaisman, Computer Science, M>, produces the triples (prefixes are omitted for brevity):
<http://myexample.org/professor/1> rdf:type prof:Professor.
<http://myexample.org/professor/1> prof:name “A. Vaisman”.
<http://myexample.org/professor/1> prof:worksIn “Computer Science”.
<http://myexample.org/professor/1> prof:gender “M”.
<http://myexample.org/professor/2> rdf:type prof:Professor.
Listing 1: Mapping a Table using R2RML |
1
|
<#TriplesMap>
|
2
|
rr:logicalTable [
|
3
|
rr:tableName "Professor"
|
4
|
];
|
5
|
|
6
|
rr:subjectMap [
|
7
|
rr:template "http://myexample.org/professor/{ID}";
|
8
|
rr:class prof:Professor;
|
9
|
];
|
10
|
|
11
|
rr:predicateObjectMap [
|
12
|
rr:predicate prof:name;
|
13
|
rr:objectMap [
|
14
|
rr:column "Name"
|
15
|
];
|
16
|
];
|
17
|
rr:predicateObjectMap [
|
18
|
rr:predicate prof:worksIn;
|
19
|
rr:objectMap [
|
20
|
rr:column "Department"
|
21
|
];
|
22
|
];
|
23
|
rr:predicateObjectMap [
|
24
|
rr:predicate prof:gender;
|
25
|
rr:objectMap [
|
26
|
rr:column "Gender"
|
27
|
];
|
28
|
].
|
In summary, given a relational database, to translate it into RDF triples, a mapping file containing the R2RML specification is created. This mapping is then applied to a given instance of the relational database.
In this paper, the mappings are generated using a common vocabulary and an ontology for the cultural domain, defined using the GOSPLtool [
27]. GOSPL is a collaborative ontology evolution methodology (it has also an associated tool), which supports stakeholders in interpreting and modeling their common ontologies in their own terminology and context, also feeding back results to the owning community. In this case, the ontology was created in a collaborative way by all the project’s participants, in an evolving manner. To illustrate the need for this ontology, consider for example that a key element in the cultural domain, namely an event, is denoted Event in the Agenda.be data and Activity in the Bozar database. Further, the cultural ontology is extended to support elements not particularly belonging to the cultural domain (defined mainly by the partners involved in these issues). This way, for instance, references to places and locations of an event must be included in the ontology. The same occurs with dates, event categories, and others.
Table 1 shows some examples.
Finally, a mapping engine takes the database instance and the mapping file to produce the RDF document. Given that the standard specification of R2RML does not support spatial data, in order to satisfy the requirements of the problem at hand, the scheme commented on above was extended as explained in
Section 3.4. For completeness and to put this decision in context, other mapping options are discussed in the next section.
3.2. Other Relational to RDF Mapping Tools and Languages
R2RML is not the only language for mapping relational to RDF data. Therefore, other options are discussed next, to understand the rationale for using R2RML in this project.
RML
The RDF Mapping Language (RML) [
28,
29] has been proposed to override R2RML’s limitation on the kind of supported data sources. For this, RML is designed as a superset of R2RML whose main feature consists of a vocabulary that defines a generic data source instead of the three kinds allowed in R2RML. RML extends the notion of the logical table, defined in R2RML, and introduces the notion of the logical source, with the property
rml:logicalsource, which can be any data input. It also defines the properties
rml:source,
rml:reference, and
rml:referenceFormulation, instead of R2RML’s
rr:tableName,
rr:column, and
rr:SQLQuery, respectively. It also defines an iterator, denoted
rml:iterator. However, opposite R2RML, RML is not a standard recommendation; thus, for this work, R2RML was chosen.
Direct Mapping
Direct mapping (DM) [
30] was the first W3C standard for mapping relational to RDF data sources. It is the simplest mapping method for such purposes. A direct mapping takes as input a relational schema and an instance of such a relational schema and produces an RDF graph as the output. Each table defines a class, using the
rdf:type predicate. Each row in a table produces a set of triples with a common subject, which is an IRI formed from the concatenation of the base IRI, the table name, the primary key column name, and a primary key value. To indicate a foreign key, a reference triple is produced with a predicate formed by the concatenation of the table name, a “ref” string, and the referencing column name. As an example, the triples in Listing 2 were produced by mapping two tables, namely
Laboratories and
Researchers.
DM is very easy to learn and use and produces as the output an RDF graph that reflects exactly the same structure as the one of the source database. However, compared to R2RML, the main drawback of DM is that it does not provide a mapping vocabulary; therefore, it does not allow using existing vocabularies to describe the data to be translated, since the name of all the predicates are the column names of the relational tables. Therefore, it would not be possible to take advantage of existing ontologies, which rules out DM as a candidate to be used in the work presented in this paper.
Listing 2: An example of a Direct Mapping |
1 | @base <http://ulb.ac.be/db/> . |
2 | @prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> . |
3 | ... |
4 | |
5 | <Laboratories/LID -1> rdf:type <Laboratories > ; |
6 | <Laboratories#LID > 1 ; |
7 | <Laboratories#Lname > “Web and Information Technologies” ; |
8 | <Laboratories#Llocation> “Building A.5”; |
9 | <Laboratories#Head_ID > 5 ; |
10 | <Laboratories#ref -Head_ID <RESEARCHERS/RID -5> . |
11 | ##... |
12 | <Researchers/RID -5> rdf:type <Researchers > ; |
13 | <Researchers#RID > 5; |
14 | <Researchers#Rname > “Jack” ; |
15 | <Researchers#Lab_ID > 1 ; |
16 | <Researchers#ref-Lab_ID > <Laboratories/LID -1>. |
The D2RQ Platform
The D2RQPlatform (
http://d2rq.org/) is a system for accessing relational databases as virtual, read-only RDF graphs. It offers RDF-based access to the content of relational databases without having to replicate it into an RDF store. D2RQ allows querying a non-RDF database using SPARQL, accessing the content of the database as Linked Data over the Web, and creating custom RDF dumps. The platform consists of three parts: (a) the D2RQ Mapping Language, with similar goals as R2RML; (b) the D2RQ Engine, which uses the mappings to rewrite Jena API calls as SQL queries against the database, passing the query results up to the outer layers of the frameworks; (c) the D2R Server, which provides, among others, the SPARQL endpoint. Requests from the web are translated on-the-fly into SQL queries using the D2RQ mapping. Therefore, it is possible to query the sources in SPARQL without using an RDF triple store. Furthermore, as mentioned above, an RDF dump could be produced. From the above, it follows that R2RML and D2RQ could work together in both ways, on-the-fly, and as an RDF dump of the triples produced by the mapping. Regarding the project described in the present work, it was considered that the D2RQ server for spatiotemporal data support would, at least, be a very hard task. Further, the solution adopted here makes it easier to support XML data sources.
3.3. Extending R2RML Sources for XML Support
As mentioned above, R2RML was originally designed to receive relational data as input, through three mechanisms: a table name, an SQL query, and an R2RML view. Therefore, a different mechanism should be used to cope with XML documents. The trivial solution would be to transform the XML document into a table. This solution may work for simple XML documents. However, when this is not the case (like in the Agenda.be data used in this project), this approach would not suffice. Therefore, the approach discussed here enriches the R2RML specification with special terms that account for XML documents. Although this solution actually modifies the standard in some sense, the modification proposed here is just a vocabulary extension, which does not prevent any standard mapping from being defined. The idea is to allow the user to provide as input a list of XPath expressions, such that the first element in this list gives the context node for all the expressions that follow. To extend R2RML, a new source
rr:xpathQuery was defined in the R2RML namespace used in the
rr:logicalTable blank node, and taking a string literal as associated object. This string contains a set of valid XPath expressions separated by the “~” character (chosen since it is not allowed in XPath expressions). It is worth remarking that, although the new predicate belongs to the R2RML namespace, a local namespace could have been used as well (e.g.,
http://ulb.ac.be/ontology/), to remain independent of possible future R2RML updates. The new predicate looks as follows:
rr:xpathQuery """//document~
./professor~
./name~
./worksIn""";
As an example, consider the data provided for this project by Agenda.be, a service that informs about cultural and artistic events in Belgium’s capital city and the institutions where such events take place. Data were provided by means of two XML documents: events.xml, containing the events and their description, and institutions.xml, containing the institutions mentioned above. Both documents were related to each other in a way such that the place and organizer appearing in events.xml correspond to an institution appearing in institutions.xml. For example, consider the event with ID 234217 in events.xml, corresponding to the presentation by mezzo-soprano Guillemette Laurens, indicated in Listing 3. The event is organized by an institution with ID 233287.
Listing 3: An event in the events.xml file. |
1
|
<Event_Instance>
|
2
|
<EventID>234217</EventID>
|
3
|
<Event_Title_FR>Guillemette Laurens (mezzo-soprano), Fuoco e cenere.</Event_Title_FR>
|
4
|
...
|
5
|
<Event_Place>
|
6
|
<Event_Place_InstitutionID>471</Event_Place_InstitutionID>
|
7
|
<Event_Place_Name_FR>Conservatoire Royal de Bruxelles</Event_Place_Name_FR>
|
8
|
...
|
9
|
</Event_Place>
|
10
|
<Event_Organisator>
|
11
|
<Event_Organisator_InstitutionID>233287</Event_Organisator_InstitutionID>
|
12
|
<Event_Organisator_Name_FR>Opus 3</Event_Organisator_Name_FR>
|
13
|
...
|
14
|
</Event_Organisator>
|
15
|
...
|
16
|
</Event_Instance>
|
Furthermore, consider the R2RML mapping file in Listing 4, which indicates how the triples are generated from the XML file.
Listing 4: A portion of the R2RML mapping file for the events.xml file. |
1
|
...
|
2
|
rr:logicalTable [
|
3
|
rr:xpathQuery """//Event_Instance~
|
4
|
/EventID~
|
5
|
./Event_Place/Event_Place_InstitutionID
|
6
|
""";
|
7
|
];
|
8
|
...
|
9
|
...
|
10
|
rr:subjectMap [
|
11
|
rr:template "http://www.agenda.be/db/Event/{EventID}";
|
12
|
rr:class gospl:Event; ];
|
13
|
|
14
|
rr:predicateObjectMap [
|
15
|
rr:predicate gospl:Event_organized_by_Institution;
|
16
|
rr:objectMap [
|
17
|
rr:template "http://www.agenda.be/db/Institution/{Event_Organisator_InstitutionID}";
|
18
|
rr:termType rr:IRI;];
|
19
|
];
|
20
|
|
21
|
rr:predicateObjectMap [
|
22
|
rr:predicate gospl:Event_taking_place_at_Institution;
|
23
|
rr:objectMap [
|
24
|
rr:template "http://www.agenda.be/db/Institution/{Event_Place_InstitutionID}";
|
25
|
rr:termType rr:IRI;];
|
26
|
];
|
The mapping produces the RDF triples in Listing 5, which inform that the event is organized by an institution with ID 233287, which is called Opus 3, and takes place at the Conservatoire Royal de Bruxelles, which has ID = 471. This semantics that is used in the translation is given by the ontology created using the GOSPL tool.
Listing 5: Triples produced by the mapping in Listing 4. |
1
|
|
2
|
<http://www.agenda.be/db/Event/234217>
|
3
|
<http://starpc18.vub.ac.be/gospl/ontology/2#Event_organized_by_Institution>
|
4
|
<http://www.agenda.be/db/Institution/233287>;
|
5
|
|
6
|
<http://starpc18.vub.ac.be/gospl/ontology/2#Event_taking_place_at_Institution>
|
7
|
<http://www.agenda.be/db/Institution/471>.
|
Data in the XML files also contain spatial information. The mapping of spatial data in XML documents is addressed in the next section.
3.4. Mapping Spatial Data
This section describes the mapping of spatial data into RDF aimed at providing LOD for Brussels. Although there are proposals to map geospatial data to RDF automatically [
12,
13], based on R2RML and RML, in the remainder, it will become clear that the problem is too complex to be solved just using automated tools. Further, as explained above, RML is not a standard, and a design decision was to work with standard tools.
Three datasets were used for this purpose, available from three Belgian companies: Agenda.be, Bozar, and STIB. Different places of interest (PoI) were included in these datasets. In order to be able to geolocate these PoIs, longitude and latitude were needed. Therefore, a conversion from full addresses of the PoIs (containing street, number, city, and postal code) into geographic coordinates was needed, a process known as geocoding. Many open-source geocoding tools are available, for example MapQuest Open (
https://developer.mapquest.com/documentation/open/nominatim-search/), OpenCage Geocoder
https://opencagedata.com/), LocationIQ (
https://locationiq.com/), and OpenStreetMap’s Nominatim (
https://nominatim.openstreetmap.org/).
Section 3.3 showed how XML data in the events.xml file provided by Agenda.be were mapped into RDF. However, the other XML document, namely institutions.xml, contained also spatial data (the institutions’ addresses). Mapping this spatial information coming from an XML document requires a previous step, explained next.
Institutions and their addresses in the source XML file are represented as shown in Listing 6.
Listing 6: An institution in the institutions.xml file. |
1 | <InstitutionID>232502</InstitutionID> |
2 | <Institution_Name_FR>Maison de la Poesie</Institution_Name_FR> |
3 | <Institution_Name_NL>Maison de la Poesie</Institution_Name_NL> |
4 | <Institution_Street_FR>r. Fumal 28</Institution_Street_FR> |
5 | <Institution_Street_NL>r. Fumal 28</Institution_Street_NL> |
6 | <Institution_HouseNumber>28</Institution_HouseNumber> |
7 | <Institution_ZipCode>5000</Institution_ZipCode> |
8 | <Institution_City_FR>Namur</Institution_City_FR> |
9 | <Institution_City_NL>Namur</Institution_City_NL> |
The institutions’ addresses must be transformed into spatial points, given that the geolocation API must receive a string representing the full address. Thus, to produce the full addresses that are the input to the geocoding process, the information in Listing 6 must be concatenated, for example, to get something like: “r. Fumal 28 5000 Namur”. To avoid transforming XML data into relational tables, XPath (
http://www.w3.org/TR/xpath/) was used instead of SQL to define the logical tables in the mapping document, as explained in
Section 3.3. However, XPath does not allow creating a new node containing the full address, which is needed in order to obtain the corresponding spatial coordinates. Thus, XSLT(
http://www.w3.org/TR/xslt) was used to produce a temporary file with such full addresses. The XSLT code is shown in Listing 7. The code browses the XML file, and each node is simply copied in a new file. When a node like “Institution_Street_FR” is reached, the zip code and city terms are concatenated, and a new node is created, with the name “Institution_Full_Address” (although data come in Dutch and French, the latter was used to find out the coordinates). The temporary file is then used as the original file on which the mapping is performed.
Listing 7: XSL code for creating a node. |
1 | <?xml version="1.0" encoding="UTF-8" ?> |
2 | <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"> |
3 | <xsl:template match="/"> |
4 | <xsl:apply-templates select="*"/> |
5 | </xsl:template> |
6 | <xsl:template match="node()"> |
7 | <xsl:copy><xsl:apply-templates select="node()"/></xsl:copy> |
8 | </xsl:template> |
9 | <xsl:template match="Institution_Street_FR"> |
10 | <xsl:copy><xsl:apply-templates select="node()"/></xsl:copy> |
11 | <Institution_Full_Address> |
12 | <xsl:apply-templates select="node()"/> |
13 | <xsl:text> </xsl:text> |
14 | <xsl:value-of select="../Institution_ZipCode"/> |
15 | <xsl:text>, </xsl:text> |
16 | <xsl:value-of select="../Institution_City_FR"/> |
17 | </Institution_Full_Address> |
18 | </xsl:template> |
19 | </xsl:stylesheet> |
After running this code, the full address for the institution above will look as depicted in Listing 8.
Listing 8: Full institution address resulting from the XSLT program in Listing 7. |
1 | <InstitutionID>3</InstitutionID> |
2 | <Institution_Full_Address>r. Fumal 28, 5000 Namur |
3 | </Institution_Full_Address> |
After this process, a spatial mapping file can be produced and applied over the new file. The mapping file is shown in Listing 9. Note that only the part relevant to the spatial mapping is shown. An XPath query was used as the logical table.
Listing 9: (Spatial) Mapping file for an institution. |
1 | ... |
2 | rr:logicalTable [ |
3 | rr:xpathQuery """//Institution_Instance~ |
4 | ./InstitutionID~ |
5 | ./Institution_Street_FR~ |
6 | ./Institution_Street_NL~ |
7 | ./Institution_HouseNumber~ |
8 | ./Institution_ZipCode~ |
9 | ./Institution_City_FR~ |
10 | ./Institution_City_NL~ |
11 | ./Institution_Full_Address; """; |
12 | ]; |
13 | |
14 | rr:subjectMap [ |
15 | rr:class gospl:Address; |
16 | rr:template "http://www.agenda.be/db/Address_of_Institution/{InstitutionID}";]; |
17 | ... |
18 | rr:predicateObjectMap [ |
19 | rr:predicate geo:geometry; |
20 | rr:objectMap [ |
21 | rr:column "Institution_Full_Address"; |
22 | rr:termType rr:Literal; |
23 | rr:data type virtrdf:Geometry;];];. |
Listing 10: A triple produced by the spatial mapping for an institution address. |
1 | .... |
2 | <http://www.agenda.be/db/Address_of_Institution/24> |
3 | a <http://starpc18.vub.ac.be/gospl/ontology/2#Address>; |
4 | <http://starpc18.vub.ac.be/gospl/ontology/2#Address_of_Institution> |
5 | <http://www.agenda.be/db/Institution/24>; |
6 | <http://www.w3.org/2003/01/geo/wgs84_pos#geometry> |
7 | "POINT(4.34926,50.8486);http://www.opengis.net/def/crs/EPSG/0/4326"^^<http://strdf.di.uoa.gr/ontology#WKT> . |
The second dataset to be mapped was the one belonging to Bozar. Bozar is Brussels’ Center of Fine Arts, hosting cultural events, concerts, and exhibitions all year long. The logical table in the Bozar mapping file was an aggregation of several tables dealing with activities. Addresses were stored in a table denoted
location_lng, with schema (
id, lng, field, content). The
field attribute contained the types of the components of a certain address (e.g., zip code, city, etc.).
Table 2 shows an example of the
location_lng table.
The five tuples in
Table 2 represent a single address. In order to perform the mapping, the five tuples in
Table 2 must be concatenated. This concatenation is performed by an SQL query and yields the tuple 〈
Mussé d’Ixelles 71
JeanVanVolsem 1050
Ixelles Belgique〉, over the schema (
fullAddress,id), as shown in
Table 3. Over this result, the mapping in Listing 11 is applied, and the result is shown in Listing 12.
Listing 11: Mapping file for locations from Bozar. |
1 | rr:subjectMap [ |
2 | rr:template "http://bozar.be/db/Locations/{id}"; |
3 | rr:class gospl:Location; ]; |
4 | |
5 | rr:predicateObjectMap [ |
6 | rr:predicate geo:geometry; |
7 | rr:objectMap [ |
8 | rr:column "fullAddress"; |
9 | rr:termType rr:Literal; |
10 | rr:data type virtrdf:Geometry;];]; |
Listing 12: Bozar: triples corresponding to location ID 231. |
1 | <http://bozar.be/db/Locations/231> |
2 | a <http://starpc18.vub.ac.be/gospl/ontology/2#Location>; |
3 | <http://www.w3.org/2003/01/geo/wgs84_pos#geometry> |
4 | "POINT(4.37238 50.83169); http://www.opengis.net/def/crs/EPSG/0/4326"^^<http://strdf.di.uoa.gr/ontology#WKT>. |
The third dataset to be mapped corresponded to STIB, the main company of public transport in Brussels. Data from STIB were stored in an SQL database that consisted of four tables:
Block, Stop, Trip and
Tripstop. A
Block represents the time elapsed between the moments when a vehicle leaves the warehouse and returns to it. The
Stop table contains the name (in French and Dutch) and location of a bus, tram, or metro stop. A
Trip is a part of a block, defined as the path between the starting point and the ending point on a particular route. Finally,
Tripstop tells the time during a trip when the vehicle reaches a stop.
Figure 2 shows the interaction between components and describes the process in more detail.
Table 4,
Table 5 and
Table 6 show instances of the dataset.
Table 7 shows how the concepts in the ontology map to the columns in the tables of the STIB database.
The spatial mapping in the STIB case was straightforward, because longitude and latitude of a stop were given; therefore, each point could be computed through an SQL query. Listing 13 shows a portion of the mapping file for a stop.
Listing 13: STIB mapping for a stop. |
1 | <#TM_stop> |
2 | a rr:TriplesMap ; |
3 | rr:logicalTable [ |
4 | rr:sqlQuery """ |
5 | SELECT * |
6 | FROM stop |
7 | """; ]; |
8 | |
9 | rr:subjectMap [ |
10 | rr:template "http://www.stib.be/stop/{stp_identifier}"; |
11 | rr:class gospl:Stop; ]; |
12 | |
13 | rr:predicateObjectMap [ |
14 | rr:predicate gospl:Stop_with_Description; |
15 | rr:objectMap [ |
16 | rr:column "stp_description"; |
17 | rr:termType rr:Literal; |
18 | rr:language "fr-BE"; ];]; |
19 | ... |
20 | rr:predicateObjectMap [ |
21 | rr:predicate gospl:Stop_with_Location; |
22 | rr:refObjectMap [ |
23 | rr:parentTriplesMap <#TM_location>; |
24 | rr:joinCondition [ |
25 | rr:child "stp_identifier"; |
26 | rr:parent "stp_identifier"; |
27 | ];];]; |
28 | . |
Listing 14 depicts the R2RML mapping document for STIB’s stop locations. Note, in the logical table, the concatenation in the SQL query mentioned above.
Listing 14: Mapping for a STIB stop location. |
1 | rr:logicalTable [ |
2 | rr:sqlQuery """ |
3 | SELECT stp_identifier, stp_longitude, stp_latitude, CONCAT(’POINT(’,stp_longitude,’ ’,stp_latitude,’); |
4 | http://www.opengis.net/def/crs/EPSG/0/4326’) as point |
5 | FROM stop """; ]; |
6 | |
7 | rr:subjectMap [ |
8 | rr:template "http://www.stib.be/location/{stp_identifier}"; |
9 | rr:class gospl:Location; ]; |
10 | ... |
11 | rr:predicateObjectMap [ |
12 | rr:predicate gospl:Location_with_Latitude; |
13 | rr:objectMap [ |
14 | rr:column "stp_latitude"; |
15 | rr:termType rr:Literal; |
16 | rr:data type xsd:double; ];]; |
17 | |
18 | rr:predicateObjectMap [ |
19 | rr:predicate geo:geometry; |
20 | rr:objectMap [ |
21 | rr:column "point"; |
22 | rr:termType rr:Literal; |
23 | rr:data type virtrdf:Geometry; ];];. |
Finally, Listing 15 shows the resulting triple for the location of Stop 6306 in
Table 4.
Listing 15: An RDF triple for stop #6306. |
1 | <http://www.stib.be/location/6306> |
2 | a <http://starpc18.vub.ac.be/gospl/ontology/60#Location> ; |
3 | <http://starpc18.vub.ac.be/gospl/ontology/60#Location_of_Stop> |
4 | <http://www.stib.be/stop/6306> ; |
5 | ... |
6 | ... |
7 | <http://starpc18.vub.ac.be/gospl/ontology/60#Location_with_Latitude> |
8 | "50.8580"^^<http://www.w3.org/2001/XMLSchema#double> ; |
9 | <http://starpc18.vub.ac.be/gospl/ontology/60#Location_with_Longitude> |
10 | "4.3681"^^<http://www.w3.org/2001/XMLSchema#double> ; |
11 | <http://www.w3.org/2003/01/geo/wgs84_pos#geometry> |
12 | "POINT(4.3681 50.8580);http://www.opengis.net/def/crs/EPSG/0/4326"^^<http://strdf.di.uoa.gr/ontology#WKT> . |
13 | ... |
It can be seen that the POINT geometry was represented in WKT. Furthermore, the latitude and longitude coordinates were produced using the mapping.
To avoid redundancy, the mapping files for the trip stops and for the trips are not shown. However, to allow the reader to be fully able to understand what will finally be at the endpoint, the triples produced for the trip stops and for the trips are shown in Listings 16 and 17, respectively.
Listing 16: RDF triples for a trip stop. |
1 | <http://www.stib.be/trip_stop/8733/at/09:06:33> |
2 | a <http://starpc18.vub.ac.be/gospl/ontology/60#Trip_Stop> ; |
3 | <http://starpc18.vub.ac.be/gospl/ontology/60#Trip_Stop_of_Trip> |
4 | <http://www.stib.be/trip/1/from/09:06:33/to/09:34:24> ; |
5 | |
6 | <http://starpc18.vub.ac.be/gospl/ontology/60#Trip_Stop_with_Stop> |
7 | <http://www.stib.be/stop/8733> ; |
8 | |
9 | <http://starpc18.vub.ac.be/gospl/ontology/60#Trip_with_passing_time> |
10 | "09:06:33"^^<http://www.w3.org/2001/XMLSchema#time> . |
Listing 17: RDF triples for a trip between 09:06:33 and 09:34:24. |
1 | <http://www.stib.be/trip/1/from/09:06:33/to/09:34:24> |
2 | a ;<http://starpc18.vub.ac.be/gospl/ontology/60#Trip> ; |
3 | <http://starpc18.vub.ac.be/gospl/ontology/60#Trip_with_Route> |
4 | <http://www.stib.be/route/1> ; |
5 | <http://starpc18.vub.ac.be/gospl/ontology/60#Trip_with_Trip_Stop> |
6 | <http://www.stib.be/trip_stop/8733/at/09:06:33> , |
7 | <http://www.stib.be/trip_stop/8282/at/09:10:36> , |
8 | <http://www.stib.be/trip_stop/8032/at/09:16:20> , |
9 | <http://www.stib.be/trip_stop/8052/at/09:18:34> ; |
10 | <http://starpc18.vub.ac.be/gospl/ontology/60#Trip_with_start_Time> |
11 | "09:06:33"^^<http://www.w3.org/2001/XMLSchema#time> ; |
12 | <http://starpc18.vub.ac.be/gospl/ontology/60#Trip_with_end_Time> |
13 | "09:34:24"^^<http://www.w3.org/2001/XMLSchema#time> . |
14 | |
15 | ... |