A major fraction of digital information is stored in le systems. File systems organize les usually in labelled directory trees and provide a minimum support for user-driven le annotation, linkage and categorization. Although le systems play a major role in knowledge organization, both in enterprise contexts as well as in the personal information sphere, they have rarely been considered in Web-based information integration. To a large extent, this can be contributed to the limited metadata support of le systems and to the lack of stable identi ers for le and directories, which makes it hard to expose these objects in a global Web. We present TripFS, a lightweight approach for exposing parts of local lesystems as Linked Data. Serving le system objects via dereferenceable HTTP URIs paves the way to integrate them with the Web of Data, and enables new possibilities of exploiting le system data, for example, by linking them with other data sources or by annotating them using Semantic Web technologies.
File systems store and organize data and documents of all sorts and of arbitrary complexity, ranging from small information snippets that can be put into single les, to large repositories of heterogeneous content that are organized within deep hierarchical structures. They act as the storage backbone of many information processing systems and can be considered as one major fundament of personal and corporate information management. Since common le systems do not impose major restrictions on creating, naming, and arranging directories and les, they support a user's individual preferences for data organization. File systems do not only store les that were created or modi ed locally: a large share of les originates from other sources, like multimedia devices, other desktops, or the Web. In corporate environments it is common to store data of collective interest on shared le servers that enable a simple form of collaboration.
Overall, le systems can be considered as one of the primary information sources both for organizations and individuals, and it is quite likely that they will remain to be important in the future. Therefore they are of high interest for information integration. However, le systems have only rarely been considered in the eld of Web-based data integration. This stems mostly from their limited possibilities of data organization1, limited metadata support, and the lack of stable identi ers for les and directories.
One promising strategy for Web-based information
integration is the Linked Data paradigm. This term denotes a
set of technologies and best practices that facilitate
information integration and linkage on a global scale. To expose
information as Linked Data means to follow simple principles
[
In this paper, we present TripFS, a lightweight approach that applies these principles for le systems in order to expose their contents as Linked Data, and therefore enables their direct inclusion in Web-based integration scenarios. It assigns stable, globally valid, dereferenceable URIs to les and directories, monitors changes in the system, serves metadata extracted from les as RDF data, and interlinks les with external data sources. It provides a plug-in architecture so that it can easily be extended to support additional le types and linking components, it adapts to the speci cs of the underlying le system, and it provides a sophisticated le change tracking component that increases the stability of le identi ers.
Because it is easy to set-up, TripFS also facilitates ad-hoc sharing of le-based resources using standardized (semantic) 1By now it seems commonly accepted that a single hierarchical scheme is insu cient for the organization of large amounts of data as we encounter them on today's desktop environments.
Web technologies. Moreover, it overcomes shortcomings of hierarchical organization mechanisms, because its metadatacentric approach allows to query for descriptive information instead of le location, and to establish multiple, orthogonal views on le system data.
After outlining application scenarios and describing how users can bene t from exposing le systems as Linked Data (Section 2), we discuss which steps have to be taken in order to realize this idea (Section 3). We present details about the TripFS architecture and implementation (Section 4). After a discussion of related work (Section 5) we conclude the paper in Section 6.
The bene ts of exposing data as Linked Data resources
are manifold [
A) Integrating File Systems into Enterprise Data. A
substantial fraction of enterprise data is available in the form
of le systems. While these data can be accessed in a
distributed context using protocols like CIFS or WebDAV, it
is di cult to integrate them in a global enterprise context
due to the lack of stable identi ers for les and
platformindependent metadata-based le access mechanisms. Linked
Data has been shown to be a viable approach for lightweight
enterprise information integration [
B) Web-based Ad-hoc Data Sharing. Despite the vast amount of possibilities for digital communication we have at our disposal, ad-hoc sharing of meaningful information (e.g., the exchange of digital documents between participants' laptops during face-to-face meetings) is still cumbersome. We can regularly observe that collaborators use e-mail or instant messaging to quickly exchange les. This approach, however, does not allow more complex data to be shared, or to exchange les together with metadata that describe their correct context. Linked Data builds on top of common Web technologies, thus any Linked Data source can be directly accessed using a common Web browser. A tool that allows users to temporarily share selected parts of their local le systems as Linked Data (which implies not only sharing plain les, but also extracted metadata, annotations, and links) facilitates e cient information exchange amongst collaborators.
C) Semantic Web-based File Annotations. Semantic
annotation and interlinking of les is badly supported today:
although modern le systems support the storage,
management, and retrieval of le annotations (e.g., extended
attributes or le forks), these data are not accessible in a
standardized and platform-independent way. This makes
the organization of les into logically connected units di
cult, and reduces the e ciency of le retrieval especially in
distributed environments. If le systems were published as
part of a Web of Data, they could be annotated and
interlinked using tools like the LEMO annotation framework [
Since the characteristics of le systems and Linked Data di er signi cantly, a number of steps have to be performed in order to lift le system data into a Web of Data: 1. Appropriate representations for les and directories have to be found, which comply to the Linked Data principles. 2. Vocabularies that convey the characteristics of data found in le systems have be to be speci ed and aligned to already existing relevant vocabularies. 3. Descriptive metadata about les have to be extracted from the le system and transformed into the RDF data model. 4. Meaningful links to other, external data sources have to be detected and established. 5. Consistency between the le system and its corresponding Linked Data representation has to be ensured. 6. Data have to be served according to Linked Data principles, i.e., in a form that is usable for both, humans and machines.
In the following we outline how each of these steps can be realized. 3.1
Within the context of a le system, les and directories
can be uniquely identi ed using their absolute paths, each
of which consists of a sequence of directory names and a le
name. The file: URI scheme [
However, le URIs are neither globally unique, since they describe a local path to a resource on a particular host, nor stable, since the referenced les and directories may be removed, moved, or renamed. Therefore they are not suitable for being used in a global Web of Data.
To solve this identi er problem, we chose to use opaque, randomly generated UUIDs, and assign them to les and directories. The usage of random UUIDs in a global distributed context is assumed to be safe since the probability of a collision is su ciently low. Further, since UUIDs are fully opaque, they do not convey information about the physical location of les and directories, and are therefore stable even when the underlying le system objects are changed. However, this requires to maintain a mapping between stable, UUID-based URIs on the one hand, and unstable, path-based identi ers on the other hand, to ensure that modi cations in the le system are properly re ected in the Linked Data representation. In Section 3.6 we outline our strategy to accomplish this.
The parent-child relationships between les and directories can be represented as RDF triples with appropriate predicates. Several triples are added to each le or directory resource that convey data that are directly retrieved from the le system: the local name (i.e., the actual le or directory name without the entire path information), the le size, and the dates of creation and last modi cation. An example of a le's RDF representation is depicted in Figure 1. Resources that represent les or directories are internally identi ed by UUID-based URNs; for serving them as Linked Data they are dynamically rewritten to HTTP URIs (cf. Section 3.7). 3.3
In order to describe les, directories, their metadata and their relations as RDF, we have developed a simple OWL vocabulary published at http://purl.org/tripfs/2010/02#. We have derived our vocabulary from existing semantic vocabularies as much as possible. However, as it is currently uncommon to expose le resources as Linked Data, we observed a lack of community-accepted vocabularies for this purpose. To the best of our knowledge, only the NEPOMUK File Ontology2 (NFO) has been speci cally de ned to model the contents of le systems. It provides terms to describe les, directories, and their properties. Our vocabulary is aligned with NFO and provides more specialized terms, according to our system's requirements.
A number of other vocabularies, however, have a general
notion of the concept of documents, and usually align this
concept to the foaf:Document class. On the other hand,
several vocabularies have a notion of collections, which can
be compared to directories in a le system; for instance,
2http://www.semanticdesktop.org/ontologies/nfo/
OAI-ORE [
To reach a maximum level of interoperability, a data source should aim to adhere to commonly accepted vocabularies as much as possible. The RDF semantics allows to arbitrarily mix di erent, unrelated vocabularies; therefore we propose|in addition to using a custom vocabulary|to model le system data using the NFO vocabulary, and to add type information from popular vocabularies like Dublin Core and FOAF as they t. By serving data using multiple, even already aligned vocabularies, we disburden data consumers from the need to perform additional inference. An example of such a mixed representation is presented in Figure 2. 3.4
Current le systems provide only a limited set of lowlevel metadata attributes associated with les such as name, owner, size, creation and modi cation date, or permission attributes. Modern le systems provide additional means to store higher-level metadata, like extended attributes or multiple data streams; however these are only useful if they are actually populated by applications, which is rarely the case. 3http://dublincore.org/groups/collections/ collection-application-profile/ 4http://dublincore.org/documents/ dcmi-type-vocabulary/ 5http://metadata.net/mpeg7 6http://musicontology.com As it is one of the Linked Data principles to \provide useful information" about a resource when a client dereferences its URI, it is desirable to extract additional, descriptive metadata from les and directories and expose them also as Linked Data. Reconsider, for example, Scenario A described in Section 2, where the value of le-system level metadata (like le size, le type, or le permissions) is limited; higher-level descriptive metadata that can be used for selective retrieval of les respectively their descriptions, e.g., via SPARQL, is required. However, the combination of these metadata enables sophisticated discovery, retrieval and access methods based on (i) the parent/child relations of le system objects, (ii) low-level le system metadata, and (iii) high-level content-based metadata.
The problem of extracting metadata from le systems has been studied for a long time. The biggest challenge in this eld is the data diversity found in le systems, which is imposed by the multitude of di erent le types. To illustrate this, currently more than 51,000 le types are registered at the popular FILExt service7. Di erent le types exhibit different internal structures, and consequently di erent metadata can be extracted. It is therefore impractical to provide metadata extractors for this large amount of di erent le types within a single software component. It is instead more feasible to de ne a generic metadata extraction framework that allows speci c extraction components for di erent le types to be plugged-in. By this, the system can be tailored to the respective application context.
In our approach, extractors read les and extract an RDF graph that contains triples representing the extracted metadata. Multiple extractors can be cascaded into an extractor pipeline and are sequentially applied to each object. The resulting RDF graphs are stored in the triple store and are 7http://filext.com then served as part of the le's and directory's description via the Linked Data interface. Extractors may extract not only le metadata (i.e., data about the documents represented by les), but also entities that are related to les (e.g., the artist who has performed the music stored in a MP3 le) and can in turn be linked to external data sources.
As an example, Figure 3 shows the RDF representation of metadata that have been extracted from two les; the rst resource represents a PDF document containing a scienti c publication, the second represents an MP3 audio le8. The blank node used to identify the artist in this example (line 9) needs to be dynamically rewritten to a stable, dereferenceable URI by the Web server (see Section 3.7). 3.5
Once les and directories are represented as RDF resources it is possible to link them to other related resources on the Web. Doing so allows clients to retrieve more, potentially interesting information about the resource. For instance, les may be classi ed according to a classi cation scheme that uses dereferenceable URIs as identi ers; in this case, clients are enabled to query for les using these terms.
The task of linking les and directories to external
resources can be accomplished by tools that provide this
functionality for generic Web resources, which usually apply
various heuristics to detect semantically related resources (e.g.,
shared identi ers or object similarity [
As a consequence, we follow the same strategy as for metadata extractors and do not provide an all-in-one solution to the problem of linking les to external resources, but instead provide a framework that allows specialized linking components to be plugged in. These linking components can access not only the raw le data, but also extracted metadata, and use this information as basis for interlinking. Like extractors, linking components return RDF triples which are added to the metadata model and served via the Linked Data interface.
As an example, Figure 4 shows to which external sources a scienti c publication and a music le can be linked, based on string similarity between the publication title and the combination of track title and artist name, respectively. In this example the PDF document from Figure 3 has been linked to the Linked Data variant of the popular DBLP publication database, and the MP3 le has been linked to resources of the MusicBrainz service. 3.6
As described in Section 3.1, it is required to mint a UUIDbased URI for each le and directory, which can be considered globally unique from a practical point of view. However, without further precautions such URIs might be quite unstable as the mapping between an UUID-based external URI and a le-based internal URI is invalidated whenever a referenced le is moved, removed, or renamed. Further, updating such les may result in inconsistencies between a le and the metadata that has been previously extracted and stored. Note that this could lead also to invalid links between resources if these were automatically created based on le metadata, as described in Section 3.5.
In order to preserve a stable mapping between these URIs
and the local les and directories they represent, we have to
employ a watcher component that is responsible for
detecting le system events that may result in di erent le URIs or
modi ed le contents of referenced les. Whenever such an
event is detected, appropriate actions have to be taken, and
the RDF model has to be updated. Note that in this sense,
the mapping between stable UUID-based URIs and instable
le and directory paths acts as a kind of translation
service between external, globally valid UUID-based URIs and
corresponding local le URIs, comparable to PURL or DOI
services [
Once the RDF-based representation of les and directories
has been generated and enriched with extracted metadata
and links to external data sources, the resulting RDF graph
can be served according to Linked Data principles. For
this purpose, internal UUID-based URNs are dynamically
rewritten to HTTP-based URIs with a con gurable host
part; e.g., http://example.com:8080/resource/<uuid>. It
is considered good practice [
TripFS has been designed as a modular service framework, which de nes plug-in interfaces that can be used to extend and adapt the system to the actual needs of the use case, the le types to be served, and the special characteristics of the underlying operating system. Such interfaces exist for RDF storage components, le metadata extractors, le linkers, and le system crawlers (responsible for crawling a con gured subtree of the le system) and watchers (responsible for maintaining the consistency of the mapping between external UUID-based URIs and internal le-based URIs). The system's architecture is depicted in Figure 6.
The TripFS core is a standalone server application, which has been implemented in pure Java, based on the Jena Semantic Web framework9. On startup, it crawls a con gured sub-tree of the local le system, applies extractor and linker components to crawled les, and stores the resulting RDF triples in a triple store (either in memory or persistent). It initializes the watcher component to monitor the exposed le system sub-tree, which in turn noti es TripFS upon changes to les or directories. Subsequently, the RDF model is updated accordingly, and extractors and linkers are re-applied to the modi ed objects.
Metadata Extraction and Linking. We have implemented simple extractors that extract low-level le metadata, such as name, le size or a hash sum that could for example be used to identify and link equal les across different TripFS instances.
Further, we have implemented extractor components based on the Aperture metadata extraction framework10, which provides a multitude of extractors for many di erent le types, including O ce documents and multimedia data. As a proof of concept, we have also implemented several linker components: one that links documents, based on their titles, to resources in the DBLP data set; one that links audio les to MusicBrainz by analyzing track title and artist 9An evaluation version of TripFS can be obtained from http://www.cs.univie.ac.at/tripfs. 10http://aperture.sourceforge.net Path-based navigation Direct file access Metadata access
Link-based navigation Extracted metadata name, and one that links les to potentially interesting DBpedia resources via the DBpedia lookup service. Both, the set of extractors and linkers are to be understood as proofof-concept; by far they do not leverage the full potential of the presented approach. However, as described before, more extractors and linkers can be integrated easily according to the needs of an actual use case.
Maintaining Consistency. We have used DSNotify [
We have implemented a generic le-feature extractor for DSNotify that extracts low-level features from local les (cf. Table 2)11. Further, we have developed a simple heuristic that calculates the plausibility that a le (described by the feature vector X) was moved to another location (the le there being described by the feature vector Y ). This heuristic consists of two parts: rst, plausibility checks are performed. For example, if the last modi cation date of le Y is before the one of le X, it cannot be a successor of X. Another example is that a le cannot become a directory or vice versa (checked by the isDirectory feature). Second, a similarity metric between the remaining features is calculated by using the strategies listed in Table 2. The resulting 11The set of extracted features used by DSNotify is overlapping but not equal to the set of metadata attributes extracted and exposed by the TripFS. In the current implementation, these latter metadata are stored in the RDF graph while DSNotify stores features in its own indices. Feature Last access Last modi cation IsDirectory Checksum Name Extension Path Size Permissions
Datatype
Similarity
Weight Date Date Bool Integer String String String Long Bitstring
Plausibility
Plausibility
Plausibility
Plausibility
Levensthein
Major MIME
type equality
Levensthein
Equality
Equality
3.0
1.0
0.5
0.1
0.1
similarities are weighted12 (e.g., the name similarity is
considered more important than equal le sizes), summed up,
and normalized. These similarities are then used by
DSNotify to detect move, remove and create events. Furthermore,
DSNotify reports update events based on changes in the
extracted feature vectors (cf. [
DSNotify periodically monitors the le subtree that is exposed by TripFS, extracts feature vectors based on the le attributes described before, and stores these vectors in an index. DSNotify uses a native C++ component for e ciently monitoring the local lesystem that makes use of the Windows API FindNextChangeNoti cation() method. We 12The selection of features as well as their weight was our own subjective choice based on several test-runs with the system. We consider an extensive evaluation of DSNotify as a tool for detecting le system events as future work. HTTP
FILE/CIFS/SMB/NFS/...
SPARQL Linked Data Interface
Watcher
/ Crawler Extractors
Linkers TripFS
Local Filesystem have also implemented a generic, yet less e cient Java-based monitor component that should work on all common platforms. This allows us to re-crawl the respective subdirectory tree only if there were actual changes reported by the operating system. The detected events are then forwarded to TripFS; the le's path is updated in the RDF model, and extractors and linkers are re-applied.
Linked Data Interface. TripFS includes an embedded Jetty Web server, which serves data from the triple store, as described in Section 3.7. It dynamically rewrites the internally used UUIDs and blank nodes to dereferenceable HTTP URIS, and provides XHTML+RDFa and pure RDF representations of le and directory resources, as well as a SPARQL endpoint. It further allows clients to directly download le contents and, in the case of local requests, to directly launch these les.
Neither component of TripFS makes any changes to the exposed le system; i.e., no special les or directories (like needed e.g., for SVN) are created. Currently, TripFS also does not provide means to modify le systems via the Linked Data interface.
Although modern le systems support the creation,
storage, management, and retrieval of le-related metadata (e.g.,
using extended attributes or le forks), they remain mostly
isolated from Web-based information integration and
exchange contexts. Even le systems that provide
sophisticated support for le annotations or links (e.g., LiFS [
As described before, le system contents are highly diverse
and heterogeneous, and contain information that is valuable
in many scenarios. TripFS presents a generic framework to
RDF
expose these contents as Linked Data, but does not by itself
extract higher-level metadata from les. For this, it relies on
additional components, of which a wide variety exists. The
Aperture metadata extraction framework was already
mentioned before; it is based on the Gnowsis adapter framework
[
TripFS is in line with a number of other generic
frameworks that allow one to expose Linked Data based on a
different underlying data representation. Frameworks in this
area include D2R [
In this paper we have presented and discussed TripFS, a service that exposes local le systems according to Linked Data principles. This approach potentially brings bene t to a range of application scenarios (cf. Section 2). In an enterprise information integration scenario (Scenario A), les are assigned stable, globally unique URIs and can therefore be referenced from external systems. Metadata that are extracted from les can be indexed by Semantic Web search engines, and links to other (enterprise-internal or external) data sources can increase the quality of information organization and data retrieval.
A lightweight component like TripFS can also be used in ad-hoc le sharing situations (Scenario B): participants in a face-to-face meeting can easily set up and start the sharing server, which exposes a certain sub-tree of their le system as Linked Data. This enables collaborators in the same network to access and retrieve these les, based not only on lowlevel characteristics like le name, but also using extracted semantic metadata and links. Using additional components, more intuitive approaches like faceted navigation can be performed on top of extracted data, and more experienced users are enabled to issue complex SPARQL queries over the le system.
A Linked Data representation of le systems also facilitates the application of Web-based annotation services (Scenario C), which overcomes the limitations of the hierarchical directory metaphor for le organization. Such annotations can refer to single les or even parts thereof, and can range from simple text-based comments to complex descriptions that may refer to external entities and concepts. TripFS makes le systems a part of a global, uniform Web of Data and therefore allows one to apply Web-based annotation techniques immediately to le system objects.
In future work, we plan an extensive evaluation of TripFS, 13http://esw.w3.org/topic/ConverterToRdf 14http://docs.openlinksw.com/virtuoso/ virtuososponger.html in particular regarding the performance and scalability of our approach. For this purpose, we aim to apply TripFS in a concrete enterprise information integration setting, and we plan to develop a simple user interface that allows end users to more easily share their les using Linked Data technologies. Further, we plan to improve and evaluate the accuracy of the DSNotify component for detecting le system events.
Additionally, we plan to introduce a more ne-grained model for selecting what le system objects are exposed via TripFS (currently one can select only a single subtree of the le system) and implement a secure HTTPS version that takes privacy considerations into account.
Parts of this work have been funded by FIT-IT grants 812513 and 815133 from Austrian Federal Ministry of Transport, Innovation, and Technology.