A large fraction of our information, both in the professional and private domains, is stored in the form of les on our personal computers. When we collaborate with co-workers or meet with friends, mechanisms for sharing les and le annotations are frequently required. However, centralized le sharing infrastructures are often not available or complicated to set up, and approaches like peer-to-peer sharing infrequently provide functionality beyond simple copying of les between machines. In this paper we present a light-weight approach for ad-hoc le sharing based on Linked Data principles. Our system exposes parts of a le system as Linked Data and allows users to interlink and annotate resources in such linked le systems. We further provide a mechanism for mounting multiple such le systems together, and for seamlessly navigating them using a common Web browser. As the exposed les and directories become Web resources, they are amenable to a large set of Semantic Web and Linked Data tools. Human and machine users may exploit such linked le systems in ad-hoc data sharing scenarios. They may further add arbitrary annotations to local and remote linked le system resources, which may also be shared among users. Finally, le system objects may be searched based on their extracted metadata and such semantic annotations.
File sharing has become a central activity in the professional and private
domains [1{3]. The sharing of les is supported by a large number of tools and
methods, ranging from email attachments over centralized le servers to
peerto-peer sharing applications. An increasingly used method is the exchange of
data via Internet-based sharing systems that may be specialized for a certain
media type (e.g., Flickr, Youtube) or of general purpose (e.g., DropBox). Users
select one or multiple of these tools to solve a particular sharing problem based
on what is shared and with whom it is shared [
In this work we focus on a particular type of data sharing, ad-hoc sharing,
which is characterized by the lack of pre-existing sharing infrastructure. Often,
the participating users and their devices are physically close; however, this is
not a precondition. Ad-hoc sharing is rather identi ed by the need to quickly
exchange data with users or devices they do not often share data with (in the
past and the future) so that the setup of heavyweight sharing infrastructures is
unfeasible [
Consider for example the following scenario: after a common vacation, Alice and Bob meet with friends to talk about their common experiences and exchange their digital photos among each other. Alice would like to give their friends a photo presentation of her and Bob's photos. Bob would like to copy some of Alice's photos to his machine but rst needs to select which ones. Further, Bob would like to add information about where a particular photo was taken (e.g., what restaurant they had that great sh menu at). These annotations should be accessible also to Alice and their friends, and they should be able to extend them. Bob would further like to explicitly link related photos, e.g., he would like to relate the photos of his daughter taken during last year's vacation to this year's photos.
Although Alice, Bob, and their friends know each other well, it is rather unlikely that they exchange data frequently; therefore the introduction of a heavyweight sharing infrastructure might be immoderate. Note that this scenario does not require the actors to meet in person|everything could also be done remotely. The scenario mentioned before could partly be solved with a centralized, online data sharing application. This would, however, raise the following issues: 1. All involved devices would require Internet access, although local connectivity would be su cient for most tasks. 2. The annotation tasks would be restricted to the functionality o ered by the particular application. 3. By uploading data to an online platform, digital copies of these data are created. Annotations would refer to these copies rather than to the original les. When a user decides to manipulate a data item locally (e.g., applying a photo lter to reduce the red-eye e ect), they would need to update the data manually on the online platform so that others can access this improved version. 4. Storing data on Web servers usually raises security and privacy issues. 5. Many existing sharing platforms handle only particular le types.
In this paper we present an alternative method for ad-hoc sharing based on
Linked Data. We present how our lesystem, TripFS [
TripFS combines several third-party components (including the Jena
Semantic Web Framework2, Aperture3 for metadata extraction, the Jetty HTTP
Server4, and the DSNotify monitoring framework [
In ad-hoc le sharing, users that do not exchange data regularly (in the past and in the future) have the short-term need to exchange le-based contents between multiple machines. As discussed, they cannot resort to permanent infrastructure (like le servers, hosting providers, or Web applications) as it is either unfeasible to set-up such an infrastructure or due to infrastructural constraints (e.g., limited connectivity, rewalls, etc.). Often, ad-hoc le sharing takes place in situations where users are co-located and have some but limited shared network infrastructure (e.g., a Wi-Fi network). Ad-hoc le sharing is of relevance both in professional and in private contexts: for instance, during a business meeting one may want to share a certain document or spreadsheet with all participants. In the private domain, one may want to exchange photos from the recent vacation with friends during a relaxed dinner.
Analyzing the related works from the le sharing domain mentioned in this
paper (in particular, [
Today, sending email attachments seems to be the predominant way of personal
le sharing [
Other common methods to share les make direct use of the World Wide Web, arguably one of the most important information channels today. The Web is well-supported by most modern devices: even low-capacity mobile devices allow users to access Web resources. It is easy nowadays to set-up personal Web presences without knowing the technical details of content markup and Web hosting. Because of their widespread adoption, Web technologies are a promising candidate for ad-hoc information sharing. However, current Web 2.0 applications that support le sharing su er from the previously mentioned issues (cf. Section 1) such as the requirement for Internet access or limited annotation support. A major drawback of such centralized systems is that they require all shared les to be uploaded to their Web servers rst. In our scenario, this means that Alice would have to upload all her vacation photos before Bob can select some for downloading them to his laptop. These digital objects are not directly connected with their digital \originals" residing on Alice's computer, meaning that changes to these les are not automatically propagated to the shared versions and vice versa. Further, Alice cannot directly bene t from annotations made to these online copies outside the hosting Web application itself.
In this paper we present an alternative le-sharing approach that does not
require a centralized infrastructure or digital copies of resources and is based
on Linked Data principles. Linked Data [
Based on the scenario outlined in Section 1, we have extended TripFS with features that allow users to easily share les across a (local) network, and to connect multiple le systems using Linked Data technologies. In the following we reconsider the scenario and describe which particular TripFS features support this use case.
One-click Sharing. When Alice and Bob meet to discuss and exchange their recent photos, both want to share folders (including subfolders) on their laptops that contain these photos5. When Alice starts TripFS on her laptop, it announces its service URL via a Zeroconf6 service, so that it can be discovered by other machines on the same network. In parallel, TripFS crawls the selected part of the local le system, extracts metadata from les, and links them to other data sources (cf. Section 2). The resulting triples are incrementally stored in the RDF store and are immediately published via the Linked Data interface.
For adding new directory subtrees to TripFS, Alice makes use of the TripFS Windows Explorer shell extension7 that allows to share a folder with a single mouse click (cf. Figure 2). When Alice clicks this button, a local Windows socket is opened and the selected directory's path is sent to TripFS. TripFS adds this directory to its list of exposed root directories and creates a new observed region for DSNotify. The shell extension reports the successful or unsuccessful outcome of this operation to the user via a popup dialog. Immediately, the folder is accessible via the Web server built into TripFS and can be accessed by devices on the network. If the newly exposed root directory lies within a directory that is already exposed, TripFS marks it as inactive in order to avoid unnecessary monitoring and crawling costs for overlapping regions. For the same reasons, TripFS deactivates all existing root directories that lie in a subtree of a newly added root directory.
Accessing Shared File Systems. Since TripFS provides both, an
HTMLand an RDF-based view on shared folders, Alice's friends can access her photos
using the Web browser installed on their laptops. If their system supports service
discovery via Zeroconf they not even have to enter the hostname or IP address of
Alice's laptop. They can navigate through the le hierarchy and download their
favorite photos (a screenshot of this interface is presented in Figure 3). They
could also use the structured data exposed by TripFS to search for les using
a visual Linked Data query builder (like, e.g., Explorator [
Alice’s Local File System
Alice’s TripFS
Bob’s TripFS Windows socket
Zeroconf discovery root favorites montenegro beach durmitor
TFS root IMG1.jpg vacation piran
tfs:mounts tfs:mountedBy IMG2.jpg rdfs:seeAlso
TFS root images 2009 prague
2008 celovec IMG1.jpg rdfs:seeAlso
IMG1.jpg a link to a GeoNames entity that has been created based on extracted GPS coordinates).
Annotating Shared Files. While he browses Alice's photos, Bob wants to annotate one of the pictures because he remembers the particular restaurant where the picture was taken. For this purpose, TripFS provides an RDF sink. This component establishes a Web resource that accepts RDF data (for instance, annotations of shared les) sent by clients via HTTP POST, and stores posted triples in a designated named graph within the TripFS RDF store. Later, these annotations are published together with metadata that have been extracted from les. For instance, Bob could drag the URL of the restaurant's Web page from his Web browser to a designated area on the TripFS HTML interface, causing an rdfs:seeAlso triple to be stored. If Bob did this for multiple les, he could later retrieve all photos linked to the restaurant's Web page through a structured query, as described before.
Mounting Other TripFS Instances. A special form of le annotation is Linked File System Mounting. This technique uses Linked Data principles to connect distributed le systems, similar to the well-known mount operation in UNIX-like operating systems (cf. Figure 2). TripFS de nes an RDF property tripfs:mounts8 to link a directory in one instance to a directory in the same or another one. TripFS provides a simple user interface for mounting remote TripFS instances, which leads to the creation of the respective triples in both involved TripFS RDF stores. Applications may add mount links by simply posting a respective triple to the RDF sink. Mount triples should be interpreted by TripFS consumers (such as the Web-based TripFS le browser) like parent-child relationships to enable seamless navigation across le system boundaries. Note that in contrast to local le systems, it is possible to create circular structures using Linked File System Mounting. Although the TripFS RDF sink rejects mount triples that would directly lead to such a situation, circles cannot be generally avoided due to the distributed, open-world nature of Linked Data. Consumers (e.g., crawlers or user interfaces) need to be aware of this possibility to avoid unwished complications like in nite loops. As mount triples reside in the annotation model of the TripFS instance they were posted to, a mount link is initially visible only to clients of this particular instance, as it is the case with UNIX mounts. However, following the idea of the Web of Data, it is reasonable to propagate the mount triple also to the remote TripFS instance, so that it can be easily followed backwards. Thus the RDF sink posts a respective tripfs:mountedBy triple to the RDF sink of the remote TripFS. Since TripFS provides stable URIs for les due to its le-monitoring component, these mount points remain valid even if a mounted le system is temporarily unavailable, or if the user decides to move a shared directory to a di erent location on their hard disk. Seamless File Browsing. While TripFS allows Alice and Bob to interlink their le systems and mutually add annotations to exposed les, this environment still provides no seamless browsing experience: for instance, le annotations are exposed only by the TripFS instance they are stored in. However, if Bob wants to add a private annotation to one of Alice's les, it should not be stored in Alice's TripFS instance but in Bob's, and he wants this private annotation to appear when he browses Alice's le system.
To overcome this issue, TripFS contains a Web-based proxy browser that dynamically fetches RDF descriptions from remote sources and enriches them with annotations from the local TripFS RDF store (cf. Figure 3). Annotations are stored in a separate RDF graph in TripFS that is merged with a resource's (remote or local) RDF graph for rendering purposes. Thus, annotations from the local store that refer (via their subject URI) to resources in the remote source are automatically mashed with the remote source's RDF descriptions: the user is presented with a single, comprehensive view of remote and local resources. Duplicate Detection. TripFS provides a simple solution for the detection of duplicate les across multiple le systems. For each published le, TripFS calcu8 tripfs:mounts is a sub-property of the tripfs:child property, an inverse property tripfs:mountedBy is available. The current version of the TripFS vocabulary is available at http://purl.org/tripfs/2010/06. lates a content-based checksum and publishes it as property of the le resource. A linker component creates owl:sameAs links between les within the published le system, as well as les in other TripFS instances that share a common checksum. For example, when Alice's TripFS is discovered by Bob's TripFS (and vice versa), this linker component is activated and creates owl:sameAs links between all duplicates found in Alice's and in Bob's shared folders. By this, Bob is enabled to immediately detect that he already copied a certain le from Alice's laptop last time they met. Further, these owl:sameAs links can be exploited to access resource copies when the originals are currently not accessible. Discovery. Currently, TripFS makes use of a Zeroconf service to discover other TripFS instances. When a new instance is discovered, the duplicate detection linker described above is activated and les with equal checksums are interlinked. One drawback of the current solution is that it is restricted to the local subnet. An alternative method would be to use URNs (e.g., PURLs) for locating physical TripFS addresses. Once the PURL of a particular TripFS instance is known (e.g., because it has been communicated via email), it would remain stable. Disadvantages would be that access to the URN service would be required, and that users have to notify these services whenever their physical address changes (e.g., due to a newly assigned IP address). However, this last step can be easily automated. Another possibility is that the creation of a guest account for a particular TripFS (see below) results in an email that sends an appropriate link to a set of recipients. This link would contain the respective TripFS location as well as the required user credentials for accessing it.
Access Control. The willingness to share data with others often depends on
whom these data will be shared with [
We are however aware that usable access control mechanisms are essential for
a system like ours. A rst, straightforward solution would be to expose les via
HTTPS and introduce password protection, which can be based on the
underlying operating system's authentication and permission system. TripFS therefore
could reuse already existing mechanisms and would avoid the need to maintain
parallel structures. Additionally, a TripFS instance owner could create a new
guest account that would be valid for a limited time with a single mouse click.
The respective credentials could then be transferred to the TripFS consumer via
out-of-band methods (e.g., via email or phone). Although this might be su
cient in the discussed ad-hoc sharing scenarios, more ne-grained access control
mechanisms and access rights, as discussed for example in [
Several studies on personal le sharing focused on particular le types (e.g.,
music or photographs [
In [
In [
In [
In this paper we described the current state of TripFS and its extensions since
our last publication [
We further presented how this linked le system can be used in ad-hoc le
sharing scenarios. Matching our system to the requirements described in Section
3 we can state that TripFS can be used as a universal le sharing tool that is not
restricted to particular le types. TripFS requires no a-priori preparations for
recipients of shared data. Users that actively share the data need a local TripFS
instance that can either be started automatically by the operating system or
by double-clicking a JAR le. TripFS allows remote users to browse the shared
contents directly on the remote machine before downloading (subsets of) it.
It thereby comprises a pull-oriented sharing strategy [
TripFS has been implemented in Java and can be used on all platforms that
support Java 1.6 or higher. In the future we aim to explore how TripFS can be
deployed on mobile devices like cell phones, which are presumably more often
involved in ad-hoc sharing situations. Then, TripFS could additionally be useful
in \sharing with myself " scenarios [