This paper introduces MOAT, a lightweight Semantic Web framework that provides a collaborative way to let Web 2.0 content producers give meanings to their tags in a machinereadable way. To achieve this goal, this approach relies on Linked Data principles, using URIs from existing resources to define these meanings. That way, users can create interlinked RDF data and let their content enter the Semantic Web, while solving some limits of free-tagging at the same time.
Among the various tools and principles that Web 2.0
introduced such as blogging, collaborative knowledge
management with wikis or on-line social networking, tagging is one
of the most interesting phenomena. While one of the main
ideas of Web 2.0 is to let users play an important role in the
process of creating content, tagging goes a step further by
letting them control the way they organise it. By adding
simple keywords, or tags, to their data or to data they
browse on-line, they can decide themselves which meta-data
must be related to any content. These tags can refer to
various and really different levels of annotation, as Golder and
Huberman [
This paper introduces MOAT - http://moat-project.org -, a framework based on Semantic Web principles designed to bridge this gap between free-tagging and semantic annotation. Its goal is to provide a simple and collaborative way to annotate content thanks to existing URIs with as little effort as possible and by keeping free-tagging habits. We will first briefly introduce the well-known limits of free-tagging and why, while a human can solve them, computers are not able to do it easily. We will then introduce how we represent the meaning of a tag and the way we model it in a machine-understandable way. We will then present the MOAT project, and start with related work about tagging vocabularies on the Semantic Web. We will describe the MOAT ontology, used to model these relationships between tags and their meanings, using URIs of existing Semantic Web resources. Next, we will see how our framework helps users to take advantage of these ideas thanks to simple tools and collaborative principles that ease the task of semantic annotation. Finally, we will overview how this approach is related to the Linked Data movement.
While tagging became popular thanks to Web 2.0 services
such as del.icio.us and Flickr, or blogging and dedicated
agregation websites like Technorati, it raises various issues
from an information retrieval point of view. These limits
mainly consists in the ambiguity and heterogeneity of tags,
as well as the flat organisation of folksonomies. Ambiguity
and heterogeneity may produce too much noise or silence
while the lack of relationship between tags makes difficult to
find related content from a given entry point. Thus, Mathes
argues that ”a folksonomy represents simultaneously some of
the best and worst in the organization of information” [
http://www.parissportifs.com/ tagged
tagged http://paris.fr
http://fr.wikipedia.org/wiki/Paris_Hilton mantic when tagging or reading some content. For example, when tagging a blog post ”paris”, a user has in mind an existing concept from the real-world, which can be a city, a person, or anything else. Yet, from a computer point of view, there is no way to make a difference since the only thing it will consider is a text string. Thus, when retrieving data, the user himself will have to manually deal with tags ambiguity to find, from a resulting dataset, in which post this tag has been used in a similar way that he had in mind (see Fig.1).
In order to represent the meaning of a tag, we first consider
the meaning it can be assigned to in a particular tagging
context (e.g. in that post context, ”paris” means a french
city). Thus, we extend the tripartite model of tagging and
folksnomies [
T agging(U ser, Resource, T ag, M eaning) (1) From this definition, we define the global meanings of a tag, i.e the list of all different meanings a tag can be assigned to. To keep a social aspect within this definition, each meaning is related to the set of users that used it:
M eanings(T ag) = {(M eaning, {U ser})}
(2)
In order to represent these meanings in a machine-readable
way, which can help to solve some of the issues raised
before, we think that Semantic Web, and especially URIs of
existing resources can play an important role. Since they
provide unique identifiers for resources of the real-world, we
believe that they are one of the most efficient way to
define it, either globally or in a tagging context. Thus, in
the two previous definitions, meanings are defined thanks
to URIs of existing resources, which can be part of any
knowledge base, as GeoNames1 or DBpedia [
Various work has been done regarding tagging and the
Semantic Web, in which we can distinguish work related to
modeling tags thanks to Semantic Web technologies and
work related to mining folksonomies from ontologies [
The MOAT ontology features a Tag class that extends the one defined in the Tag Ontology. Indeed, in our case, a Tag instance must have a single label (thus the ontology uses an OWL restriction) and its URI must respect a certain pattern that is defined by a MOAT server, as we will see later. That way, it offers common URIs for tags that can be shared across communities and social media sites. In order to represent tag meanings, the ontology can be divided in two parts. The first one, dedicated to global meanings (2), introduces a moat:hasMeaning relationship and a moat:Meaning class, that are used to link a Tag instance to all its meanings. Each moat:Meaning instance features a unique property called moat:meaningURI in order to link to the URI of an existing Semantic Web resource that represents the given meaning. Moreover it features at least one foaf:maker link (using once again a cardinality contraint in the ontology) in order to keep a trace of the user(s) that defined that URI as a meaning for the tag. The following snippet of code represents the global meanings assigned to the tag ”paris”. Here, three different meanings have been represented, while one of them is shared by two users. While the following example shows how MOAT can be used to represent tag ambiguity, the ontology can also be used to deal with hetereogenity since two different tags can share common meanings (using meaningURI), which can be helpful in multi-lingual systems where different tags refer to the same resource (e.g. paris and parigi ). 2http://tech.groups.yahoo.com/group/ywsflickr/message/2736
rdf:type tags:name
paris
The second part of the ontology defines a model for the local meaning (1) of a tag. Here, we rely on the RestrictedTagging class from the Tag Ontology, which identifies a tagging relationship between a post, a user, and a single and only tag. Thus, we introduced a moat:tagMeaning property to link a RestrictedTagging instance to the meaningful URI in this context, as show on Fig.2.
While the MOAT ontology provides a model to define relationships between tags and their meanings, this is not enough to let users easily define these meanings, either globally or locally. In order to achieve this goal, we designed a client-architecture that (1) lets users define which URIs they want to assign as meanings to their tags and (2) let them choose a URI from an existing set in a given tagging context. Furthermore, this process relies on an architecture of participation, since meanings are shared across a community and can evolve among time thanks to users themselves, that can add new meaning URIs.
Thus, the framework consists of the association of (1) a
MOAT server that can deliver the list of all global meanings
for a given tag in a community and that can be updated
by users themselves and (2) clients that provide interfaces
to define and choose the meaningful URI for a given tag in
a tagging action and then produce RDF data describing it.
Both interact with each other using HTTP, and exchange
data thanks to the previously defined ontology. To benefit
from this architecture, users simply install a client on their
favourite blogging tool while subscribing to a tag server as
they could have done with Annotea [
MOAT clients can interact with a server both in reading and writing data, respectively to retrieve meanings for a tag or to add new ones. Both actions are performed over HTTP in a RESTful way with normalized API calls3.
In order to retrieve the set of meanings for a tag, clients can use various URLs to query the server. First, since the server uses content-negociation principles, clients can simply request the tag URI to get its related RDF description, as soon as they send the correct accept header to the server. Moreover, it means that the tag itself carry some semantics, since its deferencable URI gives information about all the meanings it can be related to. As explained before, the tag URI must respect a given pattern so that the server understand it, which is: tag_uri = SERVER_BASE+urlencode(tag_label). Yet, in order to ease the task of writing MOAT clients to developers, clients can directly request the RDF file URL, or even a JSON description of the content, available at tag_uri/json, so that they can write clients without to deal with RDF. The description sent to the client is created upon request thanks to a SPARQL query sent to the triple-store which is used as a back-end of the server. That way, a MOAT server acts as a layer between a triple-store and various clients.
To update the server data, i.e. add new meanings - since a MOAT server is initially empty when a community install it - , clients simply send the URL of a file containing Tag instances and related Meanings (that is automatically created by the client itself thanks to user actions). Depending on the choice of the community, this action may require an aditional API key to allow this operation to be performed. When getting the file URL, the MOAT server imports it in the back-end store, thus merging the new meanings with already existing ones for the given tag and adding new foaf:maker statements, so that decentralized Meaning instances related to a particular tag are then combined. Hence, we immediately benefit from the collaborative aspect of this process, since as soon as one user defines a new meaning for a tag, the whole community can reuse it.
User creates content and tag it Client queries the MOAT server User chooses local meaning URI <http://sws.geonames.org/4402452/> <http://sws.geonames.org/2988507/> <http://dbpedia.org/resource/Paris_Hilton> Server returns the set for global meaning URIs User saves the content Content enters the Semantic Web
The MOAT server is currently available as a PHP5 application4 that must be plugged on the top of a triple-store. It uses a Connector class to provide an interface between the server and a RDF storage system and currently features connectors for ARC25 and for the 3store API6, using SPARUL LOAD queries to add new data.
A first client implementation was developed as a Drupal
module7. It provides an interface with any MOAT server,
export of the tagging object as a RDF file, and uses SIOC [
While MOAT can be mainly seen as a way to solve some issues of free tagging by giving meaning to tags in RDF, it must also be considered from a Linked Data point of view. By providing a way to link any Web 2.0 content to existing URIs, it may help to discover content related to these URIs thanks to lookup services such as Sindice. Furthermore, it can also be helpful to provide new tag-based search engines using Semantic Web principles that could answer advanced 4http://moat-project.org/server 5http://arc.semsol.org 6http://threestore.sf.net 7http://moat-project.org/clients 8http://sindice.com/dev/widget 9http://www.openlinksw.com/virtuoso/ 10http://wiki.foaf-project.org/SparqlPress queries like ”Find all blog posts tagged with french cities”. Finally, it can also be used to suggest related content by looking at all resources linked to a meaning URI and find posts linked to one of this resource (Fig. 5). This example shows how, from a simple free-tagging scheme, posts could be finally related thanks to the way they are linked to URIs and existing links between these URIs. Moreover, in order to provide a direct link between the tagged content and a meaning URI, one can directly rely on the sioc:topic property, thus letting SIOC further enter the Linked Data Web.
In this paper, we introduced MOAT, an ontology and a collaborative framework which goal is to let users bridge the gap between free-tagging and semantically-annotated content in a simple way. This framework relies on an architechttp://example.org/
post/1
paris http://sws.geonames.org/
3017382/ tags:taggedBy
moat:tagMeaning
http://example.org/
tagging/2
tags:taggedResource
http://example.org/
post/2
ture of participation and allows people to interlink content
with any URI from existing resources, thus letting tagging
and related services as blogs enter the Linked Data Web.
Future works regarding MOAT will mainly focus on
implementations for other platforms, as well as integrating social
networking aspects when retrieving a list of URIs from a
server for a given tag, so that a user could be suggested
in priority to use meanings that have been assigned by one
of his friend. Moreover, while MOAT does not currently
focuses on semi-automatic meaning definition for tags [