*4.1.2 TULIP unified property*

TULIP retains both the tables and lists in the same format as the hierarchical treelike structure. The structure is stored as a set of RDF triples which can represent directed graphs without order or precedence between sibling nodes. So, a set of additional RDF properties must be defined to mimic the hierarchical structures and precedence of nodes in the hierarchy. That resembles a feature of the RDF called the RDF Container; however, the TULIP has more specific features.

As TULIP retains the structure in this way, the output from a query can be projected to a new structure different from the original. It depends on how an application wants to present the information. TULIP data is stored with standard RDF properties such as rdf:type and rdfs:label. There are special RDF properties to model the treelike structure. The structure is overlaid on top of the standard RDF graph. So, Semantic Web applications that do not understand the TULIP schema can perform graph traversal and get all the contents from TULIP.

The advantage is that we can look at the data without paying attention to the origin of what type of data it came from. Instead, we can choose to look at it the way we want. For example, we can look at the data that originated from a table but think of it as if it comes from a list or vice versa. Otherwise, we may combine data in both formats. It is possible to show the data in entirely different formats, such as charts or diagrams. Therefore, if we want to create an infographic from TULIP data, we can create it dynamically and change its appearance freely in any form.

#### *4.1.3 TULIP pivotal property*

Pivotal properties or view manipulation can be done because TULIP has another type of structure modeled to mimic the multidimensional array on the RDF graph.

*TULIP: A Five-Star Table and List - From Machine-Readable to Machine-Understandable… DOI: http://dx.doi.org/10.5772/intechopen.91406*

It can store data both in column-orient (columnar) and row-orient (row-based). This allows us to query specific content of all sizes and dimensions in a single query.

Moreover, with this model, we can apply the principles of data warehouse and online analytical processing (OLAP) operations, such as rolling up the entire data in the same group, drilling down to any layer, or even slicing to cut only some axes of multidimensional content including dicing, i.e., rotate to change the perspective which means that we can filter and pivot the view of the data in TULIP format any way we want.

One of the key concepts of TULIP is using an RDF feature called RDF collection, i.e., RDF list. Apply it as a one-dimensional array to store subscripts of each level in a multidimensional array by placing all subscripts as corresponding members of the RDF collection. Then put these collections to each node of TULIP. Access to each element of TULIP can be done by a SPARQL querying for its RDF collection items that match to the corresponding subscripts.

### **4.2 Creating five-star open data table and list with TULIP schema**

Now, we will demonstrate how to create RDF triples using the TULIP schema to represent a simple table. We use the following small example table of three columns by three rows.


Because TULIP schema can represent the table in both column-oriented (column-major) or row-oriented (row-major), in this case, we represent a table with a column-major format. The sample data in the table cells is preceded by the corresponding column number, followed by the row number.

Excerpts of RDF triples used to represent the three-column by three-row table above using TULIP schema are shown in **Figure 1**.

```
ex:TableExample
   tlp:member _:Table1 .
_:Table1 rdf:type tlp:Table ;
   tlp:index 1 ;
   tlp:member _:Col1, _:Col2, _:Col3 .
_:Col1 rdf:type tlp:Column ;
   tlp:index 1 ;
   tlp:member _:Cell11, _:Cell12, _:Cell13 .
_:Cell11 rdf:type tlp:Cell ;
   tlp:index 1 ;
   rdfs:label "Cell Content 1,1" .
_:Cell12 rdf:type tlp:Cell ;
   tlp:index 2 ;
   rdfs:label "Cell Content 1,2" .
...
_:Cell33 rdf:type tlp:Cell ;
   tlp:index 3 ;
   rdfs:label "Cell Content 3,3" .
```
**Figure 1.** *RDF triples of the example table represented by the TULIP schema.*

applications to consume TULIP's five-star open data in the same way as another

*Linked Open Data - Applications,Trends and Future Developments*

TULIP is a set of RDF vocabulary (the completed TULIP specification is available at http://purl.org/tulip/spec) in the form of RDF Schema. It consists of a set of RDF properties and RDF classes that are used to define structures for data representation to completely store table and list data and preserve all of its original semantic structure. It includes basic properties needed for five-star open data such as identifiable, dereferenceable, etc., as well as the three unique properties of

TULIP has the complete preservation property in order to preserve the semantic

This is possible because TULIP has a set of properties and classes to store the content data and classes, such as tables, columns, rows, table cells, lists, list items, etc., as well as various characteristics such as table headers, spanning cells,

TULIP retains both the tables and lists in the same format as the hierarchical treelike structure. The structure is stored as a set of RDF triples which can represent directed graphs without order or precedence between sibling nodes. So, a set of additional RDF properties must be defined to mimic the hierarchical structures and precedence of nodes in the hierarchy. That resembles a feature of the RDF called the

As TULIP retains the structure in this way, the output from a query can be projected to a new structure different from the original. It depends on how an application wants to present the information. TULIP data is stored with standard RDF properties such as rdf:type and rdfs:label. There are special RDF properties to model the treelike structure. The structure is overlaid on top of the standard RDF graph. So, Semantic Web applications that do not understand the TULIP schema

The advantage is that we can look at the data without paying attention to the origin of what type of data it came from. Instead, we can choose to look at it the way we want. For example, we can look at the data that originated from a table but think of it as if it comes from a list or vice versa. Otherwise, we may combine data in both formats. It is possible to show the data in entirely different formats, such as charts or diagrams. Therefore, if we want to create an infographic from TULIP data, we

Pivotal properties or view manipulation can be done because TULIP has another type of structure modeled to mimic the multidimensional array on the RDF graph.

structure of the source table and list, such as the cell contents, table structure, column/row headers, list items, and hierarchy including some formats such as spanning cells, but not including decorative style, for example, typographic styles (bold/italics), fonts, colors, borders, backgrounds, etc. The original tables and lists

can be recreated from the RDF triple set using TULIP vocabulary.

RDF Container; however, the TULIP has more specific features.

can perform graph traversal and get all the contents from TULIP.

can create it dynamically and change its appearance freely in any form.

Linked Data.

**4.1 TULIP in a** *bud* **shell**

TULIP: interchangeable, unified, and pivotal.

*4.1.1 TULIP interchangeable property*

enumerated lists, etc.

*4.1.2 TULIP unified property*

*4.1.3 TULIP pivotal property*

**26**

\_:Item3 rdf:type tlp:Item ; tlp:index 3 ;

*RDF triples of the example list represented by the TULIP schema.*

*DOI: http://dx.doi.org/10.5772/intechopen.91406*

**4.3 Providing the way for direct data access**

*RDF graph of the example list using TULIP schema.*

the TIL model, they will look like **Figure 5** and **Figure 6**.

ex:TableExample

tlp:element \_:Table1,

\_:Col1, \_:Cell11, \_:Cell12, \_:Cell13,

**Figure 3.**

**Figure 4.**

**29**

rdfs:label "List Item 3" .

*TULIP: A Five-Star Table and List - From Machine-Readable to Machine-Understandable…*

The RDF graphs, both in **Figures 2** and **4**, are already in a hierarchical structure and sequence with tlp:index (hereafter referred to as the "TULIP indexed member, TIM model"). It can be used to recreate the original table and list. This can be achieved by graph traversal. Furthermore, generic Semantic Web applications can access the data hierarchically. This is not much different from standard RDF containers. To access each arbitrary data, we have to indirectly access by performing graph traversal step by step until we reach the data we need. Writing SPARQL queries to perform this task is not easy. Therefore, we provide direct data access by assigning "position" to each data element. Similar to creating a multidimensional array index, we mimic this concept by using the feature of RDF called collections, i.e., RDF lists, to provide a way to access data directly in a single query without any nested match (hereafter referred to as the "TULIP index list, TIL model"). We use the tlp: element to point to the blank node of each item in the flat structure and create the tlp: indexList property for each node. The tlp:indexList property has its range, i.e., object in rdf:List class of sequence number according to the tlp:index in each node of the TIM model, and ends with zero (used to specify whether to separate only single element or group of all elements under the same parent node, more about this will be discussed later). If we take the example table and list to create the RDF triples using

**Figure 2.** *RDF graph of the example table using TULIP schema.*

**Figure 2** shows these RDF triples in the RDF graph. (To make the figure more compact, we adjusted the table to a two-column by two-row dimension.)

Next, we will demonstrate how to create a simple five-star open data list using the TULIP schema by using the following example list.

	- List Item 2,1
	- List Item 2,2

i.List Item 2,2,1

• List Item 3

The RDF triples representing the above list using the TULIP schema are shown in **Figure 3**. The RDF graph of these RDF triples is shown in **Figure 4**.

```
ex:ListExample
   tlp:member _:List1 .
_:List1 rdf:type tlp:List ;
   tlp:index 1 ;
   tlp:member _:Item1, _:Item2, _:Item3 .
_:Item1 rdf:type tlp:Item ;
   tlp:index 1 ;
   rdfs:label "List Item 1" .
_:Item2 rdf:type tlp:Item ;
   tlp:index 2 ;
   rdfs:label "List Item 2" ;
   tlp:member _:Item21, _:Item22 .
...
_:Item22 rdf:type tlp:Item ;
   tlp:index 2 ;
   rdfs:label "List Item 2,2" ;
   tlp:member _:Item221 .
_:Item221 rdf:type tlp:Item ;
   tlp:index 1 ;
   rdfs:label "List Item 2,2,1".
```
*TULIP: A Five-Star Table and List - From Machine-Readable to Machine-Understandable… DOI: http://dx.doi.org/10.5772/intechopen.91406*

#### **Figure 3.**

**Figure 2** shows these RDF triples in the RDF graph. (To make the figure more

Next, we will demonstrate how to create a simple five-star open data list using

The RDF triples representing the above list using the TULIP schema are shown

tlp:member \_:Item1, \_:Item2, \_:Item3 .

in **Figure 3**. The RDF graph of these RDF triples is shown in **Figure 4**.

tlp:member \_:List1 . \_:List1 rdf:type tlp:List ; tlp:index 1 ;

\_:Item1 rdf:type tlp:Item ; tlp:index 1 ;

rdfs:label "List Item 1" . \_:Item2 rdf:type tlp:Item ; tlp:index 2 ;

> rdfs:label "List Item 2" ; tlp:member \_:Item21, \_:Item22 .

rdfs:label "List Item 2,2" ; tlp:member \_:Item221 . \_:Item221 rdf:type tlp:Item ; tlp:index 1 ;

rdfs:label "List Item 2,2,1".

\_:Item22 rdf:type tlp:Item ; tlp:index 2 ;

ex:ListExample

...

compact, we adjusted the table to a two-column by two-row dimension.)

the TULIP schema by using the following example list.

*Linked Open Data - Applications,Trends and Future Developments*

• List Item 1

**Figure 2.**

• List Item 2

• List Item 3

**28**

◦ List Item 2,1

◦ List Item 2,2

i.List Item 2,2,1

*RDF graph of the example table using TULIP schema.*

*RDF triples of the example list represented by the TULIP schema.*

**Figure 4.** *RDF graph of the example list using TULIP schema.*

#### **4.3 Providing the way for direct data access**

The RDF graphs, both in **Figures 2** and **4**, are already in a hierarchical structure and sequence with tlp:index (hereafter referred to as the "TULIP indexed member, TIM model"). It can be used to recreate the original table and list. This can be achieved by graph traversal. Furthermore, generic Semantic Web applications can access the data hierarchically. This is not much different from standard RDF containers. To access each arbitrary data, we have to indirectly access by performing graph traversal step by step until we reach the data we need. Writing SPARQL queries to perform this task is not easy. Therefore, we provide direct data access by assigning "position" to each data element. Similar to creating a multidimensional array index, we mimic this concept by using the feature of RDF called collections, i.e., RDF lists, to provide a way to access data directly in a single query without any nested match (hereafter referred to as the "TULIP index list, TIL model"). We use the tlp: element to point to the blank node of each item in the flat structure and create the tlp: indexList property for each node. The tlp:indexList property has its range, i.e., object in rdf:List class of sequence number according to the tlp:index in each node of the TIM model, and ends with zero (used to specify whether to separate only single element or group of all elements under the same parent node, more about this will be discussed later). If we take the example table and list to create the RDF triples using the TIL model, they will look like **Figure 5** and **Figure 6**.

> ex:TableExample tlp:element \_:Table1, \_:Col1, \_:Cell11, \_:Cell12, \_:Cell13,

#### **Figure 5.**

*RDF triples of the example table represented by TIL model.*

standard RDF collection such as ordered list ontology [57] and collection ontology [58] or ideas to improve SPARQL to access RDF collections more conveniently, such as the proposal of Leigh and Wood [59]). A temporary solution to the problem, while waiting for the next SPARQL specification that might have improvements in this matter, is to use a feature called Property Path provided in SPARQL 1.1 to

*TULIP: A Five-Star Table and List - From Machine-Readable to Machine-Understandable…*

For example, if we want the data in the second item of the first list in the previous example, we can query for the elements that have the tlp:indexList

These are all items that are under the second list item. In case if an only a main item is needed, we could add the last subscript by zero to match only one node. That can be done by just adding one more line of SPARQL query to match the tlp:

Similar to the list example, if we want the entire third column of the first table,

access each RDF collection item.

SELECT ?label WHERE {

"List Item 2" "List Item 2,1" "List Item 2,2" "List Item 2,2,1"

indexList (1 2 0). That is: SELECT ?label WHERE {

}

**Figure 7.**

**Figure 8.**

}

**31**

The result is: "List Item 2"

matching to (1 2) by SPARQL query as follows:

*RDF graph of the example list represented by TIL model.*

*DOI: http://dx.doi.org/10.5772/intechopen.91406*

*RDF graph of tlp:indexList (1 2 0) in detailed structure.*

?elem rdfs:label ?label .

The results are as follows:

ex:ListExample tlp:element ?elem . ?elem tlp:indexList/rdf:first 1 .

ex:ListExample tlp:element ?elem . ?elem tlp:indexList/rdf:first 1 .

?elem rdfs:label ?label .

we match the tlp:indexList with (1 3) as follows:

?elem tlp:indexList/rdf:rest/rdf:first 2 .

?elem tlp:indexList/rdf:rest/rdf:rest/rdf:first 0 .

?elem tlp:indexList/rdf:rest/rdf:first 2 .

#### **Figure 6.**

*RDF triples of the example list represented by TIL model.*

An example of the RDF graph for **Figure 6** (shows only the first five nodes) is in **Figure 7**.

Each of the tlp:indexList objects is the structure of the RDF collection, i.e., RDF list, which when extended, becomes an unbalanced binary tree structure, where leaf nodes are each member of the list, respectively. For example, the tlp:indexList (1 2 0) has a structure as **Figure 8**.

Access to each element of TULIP by SPARQL is achieved by querying its tlp: indexList that have RDF collection items matching the corresponding subscripts. The problem is that the current SPARQL specification has limited ability to directly handle the RDF collection (causing many attempts to create the alternatives to the

*TULIP: A Five-Star Table and List - From Machine-Readable to Machine-Understandable… DOI: http://dx.doi.org/10.5772/intechopen.91406*

### **Figure 7.**

\_:Col2, \_:Cell21, \_:Cell22, \_:Cell23, \_:Col3, \_:Cell31, \_:Cell32, \_:Cell33 .

\_:Table1 rdf:type tlp:Table ; tlp:indexList ( 1 0 ) . \_:Col1 rdf:type tlp:Column ; tlp:indexList ( 1 1 0 ) . \_:Cell11 rdf:type tlp:Cell ; tlp:indexList ( 1 1 1 0 ) ; rdfs:label "Cell Content 1,1" .

\_:Cell12 rdf:type tlp:Cell ; tlp:indexList ( 1 1 2 0 ) ; rdfs:label "Cell Content 1,2" .

\_:Cell33 rdf:type tlp:Cell ; tlp:indexList ( 1 3 3 0 ) ; rdfs:label "Cell Content 3,3".

ex:ListExample

...

*RDF triples of the example list represented by TIL model.*

tlp:element \_:List1,

\_:List1 rdf:type tlp:List ; tlp:indexList ( 1 0 ) . \_:Item1 rdf:type tlp:Item ; tlp:indexList ( 1 1 0 ) ; rdfs:label "List Item 1" . \_:Item2 rdf:type tlp:Item ; tlp:indexList ( 1 2 0 ) ; rdfs:label "List Item 2" .

\_:Item22 rdf:type tlp:Item ; tlp:indexList ( 1 2 2 0 ) ; rdfs:label "List Item 2,2" . \_:Item221 rdf:type tlp:Item ; tlp:indexList ( 1 2 2 1 0 ) ; rdfs:label "List Item 2,2,1" . \_:Item3 rdf:type tlp:Item ; tlp:indexList ( 1 3 0 ) ; rdfs:label "List Item 3" .

An example of the RDF graph for **Figure 6** (shows only the first five nodes) is in

Each of the tlp:indexList objects is the structure of the RDF collection, i.e., RDF list, which when extended, becomes an unbalanced binary tree structure, where leaf nodes are each member of the list, respectively. For example, the tlp:indexList (1 2 0)

Access to each element of TULIP by SPARQL is achieved by querying its tlp: indexList that have RDF collection items matching the corresponding subscripts. The problem is that the current SPARQL specification has limited ability to directly handle the RDF collection (causing many attempts to create the alternatives to the

\_:Item1,

\_:Item3 .

\_:Item2, \_:Item21, \_:Item22, \_:Item221,

...

*Linked Open Data - Applications,Trends and Future Developments*

*RDF triples of the example table represented by TIL model.*

**Figure 5.**

**Figure 6.**

**Figure 7**.

**30**

has a structure as **Figure 8**.

*RDF graph of the example list represented by TIL model.*

#### **Figure 8.**

*RDF graph of tlp:indexList (1 2 0) in detailed structure.*

standard RDF collection such as ordered list ontology [57] and collection ontology [58] or ideas to improve SPARQL to access RDF collections more conveniently, such as the proposal of Leigh and Wood [59]). A temporary solution to the problem, while waiting for the next SPARQL specification that might have improvements in this matter, is to use a feature called Property Path provided in SPARQL 1.1 to access each RDF collection item.

For example, if we want the data in the second item of the first list in the previous example, we can query for the elements that have the tlp:indexList matching to (1 2) by SPARQL query as follows:

SELECT ?label WHERE { ex:ListExample tlp:element ?elem . ?elem tlp:indexList/rdf:first 1 . ?elem tlp:indexList/rdf:rest/rdf:first 2 . ?elem rdfs:label ?label .

}

The results are as follows:

"List Item 2"

"List Item 2,1"

"List Item 2,2"

"List Item 2,2,1"

These are all items that are under the second list item. In case if an only a main item is needed, we could add the last subscript by zero to match only one node. That can be done by just adding one more line of SPARQL query to match the tlp: indexList (1 2 0). That is:

SELECT ?label WHERE {

ex:ListExample tlp:element ?elem . ?elem tlp:indexList/rdf:first 1 . ?elem tlp:indexList/rdf:rest/rdf:first 2 . ?elem tlp:indexList/rdf:rest/rdf:rest/rdf:first 0 . ?elem rdfs:label ?label .

}

The result is:

"List Item 2"

Similar to the list example, if we want the entire third column of the first table, we match the tlp:indexList with (1 3) as follows:

```
SELECT ?label
   WHERE {
           ex:TableExample tlp:element ?elem .
           ?elem tlp:indexList/rdf:first 1 .
           ?elem tlp:indexList/rdf:rest/rdf:first 3 .
           ?elem rdfs:label ?label .
   }
   The results are as follows:
   "Cell Content 3,1"
   "Cell Content 3,2"
   "Cell Content 3,3"
   Alternatively, if we want the whole third row, we match the tlp:indexList with
(1 ? 3) where "?" at the second subscript position is the tlp:Column level, which we
will not filter. So we will get every column.
   SELECT ?label
   WHERE {
           ex:TableExample tlp:element ?elem .
           ?elem tlp:indexList/rdf:first 1 .
           ?elem tlp:indexList/rdf:rest/rdf:rest/rdf:first 3 .
           ?elem rdfs:label ?label .
   }
   The results are:
   "Cell Content 1,3"
   "Cell Content 2,3"
   "Cell Content 3,3"
```
When shown as RDF graph, it will look like **Figure 10**. (To make the graph more compact, we have resized the table to two columns by two rows and remove some nodes, and many edges of tlp:element have also been omitted. In fact, tlp:element

*TULIP: A Five-Star Table and List - From Machine-Readable to Machine-Understandable…*

Likewise, the TH model RDF triples of the example list are in **Figure 11**. When shown as the RDF graph, it will look like **Figure 12** (showing only some tlp:element

will point to every blank node).

*DOI: http://dx.doi.org/10.5772/intechopen.91406*

edges to make the graph more convenient and clear).

ex:ListExample

...

*RDF triples of the example list represented by TH model.*

*RDF graph of the example list represented by TH model.*

*RDF graph of the example table represented by TH model.*

**Figure 11.**

**Figure 12.**

**33**

**Figure 10.**

tlp:element \_:List1,

tlp:member \_:List1 . \_:List1 rdf:type tlp:List ; tlp:index 1 ; tlp:indexList ( 1 0 ) ;

\_:Item3 rdf:type tlp:Item ; tlp:index 3 ; tlp:indexList ( 1 3 0 ) ; rdfs:label "List Item 3" .

\_:Item1,

\_:Item3 ;

tlp:member \_:Item1, \_:Item2, \_:Item3 .

\_:Item2, \_:Item21, \_:Item22, \_:Item221,
