One of the main characteristics of Linked Open Data (LOD) is the exclusive application of standards published and maintained by the World Wide Web Consortium. This strict adherence is kept on all levels, ranging from the identi cation and transportation (URI, HTTP) to the interpretation (RDF, RDFS, OWL) of resource descriptions. Because these standards are open and accessible to everybody, broad acceptance and proliferation of LOD technologies in Web-based applications and services are enabled. On typical desktops, however, the majority of applications are not aware of Web standards, but use hierarchical le systems to organize and store information. This results in a gap between the two distinct information spaces of the Web and the desktop. To bridge this gap, we propose a virtual le system representation of LOD sets, through which they can be accessed as if they were present in the le system and thus easily be used within desktop applications.
The goal of Linked Open Data (LOD) [
A large number of applications, however, are executed in desktop environments and are, in turn, designed and built under entirely di erent assumptions w.r.t. information representation, storage, and exchange. On the desktop, the le system is the main mechanism for the storage and organization of data, and consequently data exchange on the desktop is mostly implemented based on les. This is re ected by the fact that many applications provide import and export lters, which allow them to read and write di erent le formats and hence exchange data with other applications. A number of de-facto standard le formats exist which are expected to work across platforms and applications.
The Semantic Web, and Linked Open Data in particular, are distinct from desktop environments in this respect. On the Web, di erent formats and mechanisms are in operation. As a consequence, we can observe distinct information spaces as well as conceptual and technical gaps between these two worlds. To bridge them, it is desirable to build a bridge between LOD and desktop applications so that desktop users can directly access and integrate information from LOD sources, but continue to work with the applications they are familiar with. For instance, it would be desirable to directly insert a textual description of Berlin within one's favourite word processing application, or to seamlessly load structured descriptions about this city into a spreadsheet tool.
In this paper we present such a bridge: we propose a mechanism that represents LOD sets as virtual le systems, which enables applications and users to directly access resource descriptions and their representations. Such a representation can be useful in a number of scenarios, which we describe in Section 2. In Section 3 we discuss our mapping approach and a prototypical implementation. We also discuss structural di erences between le systems and LOD principles, and how the LOD technology family could be improved in order to extend their applicability in Section 4. 2.
The possible usage scenarios of le systems are manifold, as we can observe on our own desktop computers. A number of them are especially interesting in the context of Linked Open Data. In this section we outline such scenarios that would bene t from a virtual representation of LOD sets.
Most desktop computer users are familiar with navigation in hierarchical le systems. The visual rendering of le system structures, provided by applications like Windows Explorer or Apple Finder, is similar on all desktop operating systems. They indicate les as atomic information entities, which are grouped by hierarchical collections, i.e., directories. Navigation within the directory hierarchy of a le system is understood by most end users: directories can be \opened" and their contents can be inspected. Similarly, les can be opened with their respective applications in order to view and manipulate their content.
A virtual le system representation of Linked Open Data applies the metaphors of directories and les to these data: it allows users to navigate through the RDF graph provided by a LOD set as if it was a hierarchical le structure on one's personal desktop. Hence users are not required to mentally \switch" between the Web and the desktop contexts.
The data found in LOD sources can be relevant in many scenarios. However, common desktop applications usually do not provide means to import data directly from the Web, neither in \traditional" formats (e.g., HTML pages) nor in the form of RDF. Consequently, a user of such applications who wishes to reuse information from LOD sources is forced to perform intermediate data conversion. First, the data of interest must be located, then it must be downloaded to a local le, and as a nal step it must be converted into a format that can be read by the target application.
To e ciently perform these tasks, extensive knowledge of LOD technologies (SPARQL and RDF) and of the target application's data formats is needed. With a virtual le representation of LOD, at least the rst two steps can be executed by the virtual le system driver, allowing users and applications to access data as if they were stored in the local le system. Additionally, conversion from RDF to typical desktop application le formats that can be interpreted by many applications (e.g., Rich Text Format or Commaseparated Values) can be performed directly by the virtual le system driver.
Information resources on the desktop are typically
organized using hierarchical le systems, which allow users to
arrange documents within a tree of (nearly) arbitrarily named
directories. Even applications that do not follow this pattern
store and organize their data in le system structures [
The integration of resources other than les, like web resources, into le systems is often cumbersome. Many systems allow users to link web resources (URLs) into hierarchical le systems by saving the target address into a special le. This le however can often not be used by applications that operate on the le system. By representing Linked Open Data (i.e., resource descriptions on the Semantic Web) as virtual le systems, these data can be directly integrated with other le-based resources, and it can be seamlessly processed by humans and applications. 3. 3.1
A number of conceptual di erences between Linked Open Data and hierarchical le systems have to be considered in order to de ne a useful and valid representation. In the following we outline these issues and, where possible, describe directions how to solve them.
Structural Mismatch. Linked Open Data is published in the RDF format, which essentially is a graph model: resources and literals can be interpreted as (labelled) nodes, and property relationships between them can be interpreted as directed, labelled edges. In contrast, le systems are trees, which consist of inner nodes (directories) and leaf nodes ( les). In hierarchical le systems, each node is labelled, and there exists only one type of relationship between nodes (contains). Consequently, in order to prevent information loss, the labelled edges of the RDF graph must be represented as labelled nodes in the le system representation. A graph cannot be reduced to a tree without the loss of edges, which in the case of RDF means information loss. However, one can circumvent the strictly hierarchical structure of le systems using shortcuts1. The representation of edges in the RDF graph model as le system shortcut allows for a complete graph representation.
Entry Point. File systems, due to their hierarchical structure, have a natural entry point, the root directory. This entry point is present in every le system and commonly serves as the starting point for activities like browsing and searching, but also as reference for unique naming within the le system tree. A graph structure does not have such a natural starting point. Two possibilities for selecting a starting point for a tree-based representation of a graph can be derived from typical usage patterns of the (classic) Web: users either are aware of a URL they want to visit (e.g., by using a bookmarking system) and navigate directly to the corresponding Web site, or use search engines to nd resources that ful l their information needs.
Naming. RDF, the meta model for representation of
Linked Open Data, uses URIs [
Naming in le systems is di erent: the uniqueness of le and directory names is ensured only locally, i.e., in the context of the objects' parent directory. A le's full path is unique within the local machine context 1Di erent names and semantics are used for such mechanisms in di erent operating systems; e.g., alias or symbolic link. Essentially all these mechanisms allow le system objects ( les or directories) to virtually appear in multiple locations, i.e., they can be accessed via multiple paths. and can be interpreted as a sequence of local names. In this regard, le systems are more restrictive than RDF, which allows for a lossless mapping from URIs to le names. However, the syntactic rules for valid URIs di er from the rules for valid le and directory names (for instance, several characters that are allowed in URIs are not allowed in le names), which must be solved by suitable escaping algorithms.
Literal Values. This naming mechanism does not
apply to literals. In fact, literals are more convenient
and intuitive substitutes for URIs (cf. Section 3.4 of
[
In le systems, the actual information to be used and
processed by applications is stored within les, and
not in the structure of the le system hierarchy. This
means that le-based applications are designed to read,
write, interpret, and modify not directory hierarchies,
but le contents. Thus it is more practical and
convenient to represent RDF literal values as le content
rather than to encode them as le or directory names.
Resource Representations. One basic idea of the
Semantic Web is that it is used to describe resources.
The actual representation of a resource, however, is
out of the scope of RDF since it deals only with the
metadata layer. The connection between a resource's
descriptions and its actual representations is usually
established by dereferencing its URI. By doing so a
client can expect to retrieve a resource's
representation (in the case of information resources) or a
RDFbased metadata record about a resource (in the case
of non-information resources, cf. [
Since le systems follow a relatively simple underlying
model, the degrees of freedom for modeling a virtual LOD
representation are limited. Summing up the issues described
2Di erent le systems provide mechanisms to represent
multiple content streams for les; e.g., Alternate Data Streams
[
1. Resources cannot be mapped to les. Since le systems provide a manifestation of inner structure only for directories through the containment relationship described before but not for le contents, RDF resources cannot be mapped to les, but must be mapped to directories in order to preserve their structured descriptions. 2. Properties cannot be mapped to les. An RDF property establishes either a relationship between two resources or between a resource and a literal string. Again, the only model element of le system that can be used to express such relationships between objects are directories and the elements they contain. 3. Literal values should be represented inside les. As described before, applications should be enabled to directly access literal values, but this can only be accomplished if they are represented as le contents. 4. Resource representations should be considered. In le systems, contents and metadata are tightly integrated, and a le cannot be considered separate from its contents. To sustain this assumption on which le-based applications are designed, it is desirable to include resource representations of various content types into the virtual le system, thus extending the scope of RDF. 5. A meaningful root node should be de ned. For a proper le system representation, a meaningful root node should be de ned that is useful both to humans and to machines. This root node should also be chosen so that it provides a permanent mapping of resource identi ers (URIs) to le paths in order to allow to maintain le paths even if the LOD set changes.
We have de ned a virtual le system representation of Linked Open Data sources that considers these conditions. In the following we present this approach and discuss our prototypical implementation. 3.2
According to the considerations described before, we
represent each RDF resource within a LOD set as a virtual
directory (cf. Figure 1), and we collect all (known) resources
within one directory called /!resource/. Hence each
resource obtains a unique absolute path, which corresponds to
the RDF principle that each resource has a globally unique
URI. To determine the name of the virtual resource
directory, we convert full URIs to quali ed names (cf. Section 4
of [
The representation of each resource as a virtual directory allows us to collect all information about this resource 3It depends on the operating system which characters are a ected by this encoding: for instance, Windows does not permit colons in le systems, whereas in UNIX-based operating systems they can be used as long as they are escaped properly. within one single point in the virtual le system, and also to uniquely refer to this resource across the entire le system.
Within the resource directory we can now represent all available information about this resource, i.e., properties that have this resource as subject. Since a property can have multiple values we represent each property as virtual directory that contains all corresponding values. This is done di erently for object properties (i.e., properties whose value is a RDF resource) and datatype properties (i.e., properties whose value is a literal). For the former, we represent the property value resource as a symbolic link4 that refers to the resource's virtual directory, as described before. This (i ) avoids long pathnames, which otherwise would reduce the system's usability and may cause implementation problems, and (ii ) avoids cycles and hence inde nite hierarchy depths. An example for the representation of a object property is depicted in Figure 2.
We represent the lexical representation of datatype property values (i.e., literals) not as le name or directory name, but within the contents of a virtual le, which is located within the virtual property directory. Since a resource may have multiple properties with the same property URI but di erent literal values, we distinguish the single value les by numbering them (see Figure 3). This mapping provides the possibility to directly read literal strings from applications, but also to search for them using le system fulltext indices.
In addition to representing a resource's \outgoing"
properties (i.e., triples that have this resource as subject) we also
represent \incoming" properties (i.e., triples that have this
resource as object) for convenience reasons. This
representation allows a client user or application to backwards-traverse
edges in the RDF graph. To distinguish incoming properties
from outgoing ones, we apply the same naming convention
as popular LOD browsers (e.g., Tabulator [
Finally, we include resource representations in our
virtual le system in order to enable applications and users
to directly access them without the need to deal with the
HTTP protocol or other retrieval mechanisms. We
represent resource contents as les that reside within the virtual
resource directory, and include the representation's content
type in the le name in order to distinguish them. Since
the Web architecture [
The combination of all these mappings constitutes a virtual tree-based representation of Linked Open Data sets. Using this representation, users and applications are enabled to navigate through the virtual directories that represent resources and properties, and to access property values and resource representations, which are stored as virtual les. All resources whose URIs are known can be used as starting point, since they are represented under the virtual /!resource/ directory.
However, a LOD set may contain descriptions about large numbers of resources, and retrieving all known resources from the endpoint is an expensive task. As described in / !resource /!resource/ dbpedia:Berlin / content-application_rdf.xml /!resource/ dbpedia:Berlin / content-text_rdf.n3 /!resource/ dbpedia:Berlin / content-text.html /!resource/ dbpedia:Berlin / content-text.csv Section 3.1 it is very common to use full text search engines as starting point for information retrieval from the Web. To provide similar behavior for linked data that is represented as virtual le system, we allow the user|in addition to the possibility of directly navigating to a virtual resource directory|to execute full text searches by creating a directory in the virtual le system's root folder, whereas the directory name is used as search term5. When such a folder is created, a query is issued against the LOD set and symlinks for the resulting resources are created within that directory. Such a behaviour is also implemented in a number of application-speci c virtual le systems, some of which we present in Section 5.
Figure 6 shows an extract of a complete le system tree
that represents data from one of the most popular LOD
sources, DBpedia [
We have implemented a virtual le system driver called LODFS6 that represents data from an arbitrary SPARQL endpoint as virtual le system. This implementation uses the FUSE-J toolkit7 which allows for the implementation of le system drivers in the user space and thus disburdens the developer from the need to develop kernel extensions. Currently, FUSE le systems can be used on Linux, FreeBSD, and Mac OS X platforms.
A LODFS instance is always bound to one SPARQL endpoint and potentially represents all data that is available through this endpoint. When the LODFS driver is launched, it only provides a root directory that contains an empty /!resource/ directory. The preferred way to access re5For a discussion on the practical applicability of fulltext queries in the context of Linked Open Data, refer to Section 4.1. 6LODFS: http://lodfs.sourceforge.net 7FUSE-J Framework: http://fuse-j.sourceforge.net dbpedia:2raumwohnung sources is through a full text search. Whenever a user creates a directory within the driver's root directory, a corresponding SPARQL SELECT query is issued, the resulting resources are added under the /!resource/ directory, and symlinks are created within the virtual search directory. Alternatively, the user can directly access resource descriptions by creating (mkdir) or changing into (cd) the corresponding resource directory, e.g., /!resource/dbpedia:Berlin/.
The implementation retrieves resource descriptions only on demand : when a request (e.g., a directory listing) to a virtual resource directory is issued, and the data of the resource has not yet been retrieved, a SPARQL DESCRIBE query is issued, and the resource representations of various types (cf. Figure 5) are retrieved. Then, the resulting resources are represented as virtual directories, les, and symlinks.
Figure 7 shows a transcript of a console session that interacts with a LOD dataset. In this example, a full text search directory is created and its contents are listed. Then, all properties and representations of one resource (dbpedia:Wannsee) are listed. Finally, the contents of all literal values for the resource's rdfs:label property are printed.
So far we have discussed a number of conditions for a virtual le system representation of LOD data (Section 3.1). In Section 3.2 we have presented our mapping approach, $ cd /Volumes/lodfs $ ls $ mkdir berlin $ cd berlin $ ls 0 dbpedia:Berlin@ ->
/Volumes/lodfs/!resource/dbpedia:Berlin 0 dbpedia:Wannsee@ ->
/Volumes/lodfs/!resource/dbpedia:Wannsee [...] $ ls dbpedia:Wannsee 26093 content-application.rdf+xml* 17060 content-text.csv* 30331 content-text.html* 17417 content-text.rdf+n3* 0 foaf:depiction/ 0 foaf:img/ 0 geo:lat/ 0 geo:long/ [...] $ cat dbpedia:Wannsee/rdfs:label/* "Wannsee"@es "Gro er Wannsee"@nl "Gro er Wannsee"@de "Gro er Wannsee"@da [...] $ and in Section 3.3 a prototypical implementation of this approach was described. From the experience we have gained in the course of the design, implementation, and usage of our approach, we can observe a number of open issues in the context of LOD related technologies. In the following we outline several of these issues in order to indicate directions for further research and development. 4.1
URIs play a fundamental role in Linked Open Data, as they are used for the identi cation of resources and properties. Although they are not primarily designed for human consumption, URIs are also often used for the visual rendering of resources in user interfaces. A number of vocabularies provide properties designed to describe a resource's humanreadable label (e.g., rdfs:label or skos:prefLabel), however their presence is not guaranteed, in which case the URI serves as fallback for rendering. Moreover, a resource may have multiple rdfs:label property values, or di erent resource's labels may be equal, which causes confusion in user interfaces.
URI Prefixes.
Long URIs are hard to render in a user interface, and they are also not directly suitable to be used as le names or directory names because of forbidden characters. In our implementation, QNames are used to abbreviate URIs with human-friendly shortcuts, and a number of URI pre xes (e.g., rdf: or owl:) can be regarded as commonly accepted. However, in principle there exists no globally valid mapping for URI pre xes since they are by de nition valid only in a local context. For generic client applications like our virtual le system it is therefore hard to determine which URIs are used and which URI pre xes can be applied. URI pre xes can be embedded in the various RDF serializations (e.g., using namespaces in the RDF/XML serialization), but in practice often default pre xes are applied which have no meaning to the user (e.g., j_0: and similar pre xes are regularly found in RDF serializations produced by the Jena Semantic Web framework).
To overcome this drawback one could imagine metadata that describes a LOD set, and also indicates which vocabularies and URI pre xes are used therein. The recently presented Vocabulary of Interlinked Datasets (voiD)8 includes a property (void:vocabulary) to describe which vocabularies are used within a dataset, but does not consider the de nition of preferred URI pre xes. Thus, it would be an option to extend the voiD vocabulary towards this direction.
Another approach to solve this problem is the usage of lookup indices like the recently presented prefix.cc service9, which maintains a list of mappings from pre xes to URIs. Developers can use this service to submit their pre xto-URI mapping and to look up the full URI for a given pre x. prefix.cc resolves pre x naming con icts using a voting mechanism, hence the most popular pre x mapping is determined by the user community. Currently, however, this service does not allow clients to query the preferred prex for a given URI, which reduces its applicability for the purposes described in this paper.
The Web Architecture [
A number of RDF language features (especially
anonymous resources, collections, and rei cation) are considered
problematic in the context of Linked Open Data (cf. [
Currently, SPARQL provides fulltext search only through
the usage of the regex() lter (cf. Section 11.4.13 of [
WHERE { ?s ?p ?o .
On the other hand, di erent SPARQL implementations
provide fulltext search through proprietary query language
extensions. For DBpedia, fulltext queries can e ciently be
issued through the virtual bif:contains property (cf.
Figure 9), which is de ned by the underlying OpenLink
Virtuoso implementation [
Linked Open Data does not provide a mechanism to
update data, hence the virtual le system is read-only. There
exist proposals for an update extension to SPARQL (e.g.,
the SPARQL/Update proposal which is currently a W3C
member submission [
There exist a number of di erences regarding the le system implementations of common operating systems. For instance, the meaning of a backslash (n) in a path expression di ers under Windows, where the backslash separates sub-directory names, and under Linux/Unix-based systems, where it is used to escape special characters. Even on a single platform the behaviour can be di erent: for instance, Mac OS X allows the usage of slashes (/) in le names, but the underlying Unix le system implementation converts them to colons. Our prototype implementation follows the convention of using a colon to separate URI pre xes from the local names; consequently these directory names show 10DBpedia SPARQL endpoint: sparql 11pushback | Write Data Non-RDF Sources:
Back From RDF to http://esw.w3.org/topic/ up with a slash in the Finder (cf. Figure 10). Of course, for a Windows implementation a di erent separator would have to be chosen.
Many operating systems impose a limit on the maximum number of characters for absolute le paths. Although object properties are realized using symbolic links in our implementation, the virtual path to a resource may become very long, especially in the case of cyclic RDF properties. Currently this can be solved within applications and le browsers by resolving symbolic links. 5.
The current state of the art w.r.t. the consumption of
Linked Open Data for end users are RDF browsers, of which
a number have been presented previously (e.g., [
A number of approaches have been presented how to use
(semi-)structured object annotations for the generation of
virtual le system views; e.g., by interpreting le path
elements as AND-combination of attribute/value pairs [
The libferris virtual le system [
A number of approaches comparable to ours can be found for speci c web applications, including ickrfs13, GmailFS14, or youtubefs15. These approaches translate le system calls to operations on the underlying service API and represent data from the service's account as virtual les. Services that deal with multimedia content like the ones described here are predestined to be represented as les since their APIs provide a uni ed view on content but also on annotations like tags or user comments. To the best of our knowledge, the approach presented in this paper is the rst one that uses arbitrary data accessible via a SPARQL endpoint and additionally considers fulltext search and resource representation in conjunction with RDF descriptions.
In this paper we have shown how Linked Open Data sets can be represented as virtual le systems, and hence be directly used by le-based applications without further conversion steps. We have sketched a number of potential application scenarios for such an implementation, and we have discussed design considerations that in uence our mapping.
Our prototypical implementation maps RDF resources to virtual directories, which contain sub-directories and les that represent object and datatype properties. We additionally include resource representations of various content types into our virtual le system in order to allow applications to directly operate on these data. From our implementation we have drawn a number of conclusions and issues that indicate how the Linked Open Data technology family can be extended and improved in order to better support generic client applications.
Currently however a virtual le system based on LOD is read-only since there exists no standardized way to modify linked datasets. We believe that controlled write access could signi cantly improve the applicability of Linked Open Data and related techniques, not only for virtual le systems as presented in this paper; thus we will investigate more towards this direction in the future. 12Redland RDF Libraries: http://librdf.org 13http://manishrjain.googlepages.com/flickrfs 14http://richard.jones.name/google-hacks/ gmail-filesystem/gmail-filesystem.html 15http://code.google.com/p/youtubefs/
Parts of this work have been funded by FIT-IT grants 812513 and 815133 from Austrian Federal Ministry of Transport, Innovation, and Technology. The author thanks Niko Popitsch, Bernhard Haslhofer, and Stefan Zander for valuable comments on this paper.