The Similarity Ontology

You are granted a license to use, reproduce and create derivative works of this document under Creative Commons Attribution 3.0 Unported License. This copyright applies to The Similarity Ontology specification and RDF.

Abstract

This specification defines a small ontology for similarity called MuSim. In MuSim, the association between two (or more) Things is a class to be reified rather than a property. This allows us to embrace the complexity of associations and accommodate the subjectivity and context-dependence of musical and multimedia similarity. Although this ontology was designed with music similarity in mind, it can readily be applied to other domains.

Status of this Document

This is a work in progress and as such is subject to change. Comments are very welcome, please send them to kurtjx gmail.

Appendixes

1 Introduction

The MuSim ontology aims to describe the associations between musical items and is motivated by a variety of use cases. Generally we would imagine these items to be music artists (a mo:MusicArtist) or music tracks (a mo:Track) although there are definitely other possibilities. With MuSim, we envision the creation of a distributed music information system that uses data about associations between musical items to allow for recommendation and discovery in a wide variety of contexts. Sometimes MuSim RDF would be stored directly in triple stores, sometimes it would be generated on demand (eg using some similarit system based on vector space).

While the Music Ontology deals primarily with objective attributes of music-related items such as authorship, composition, performance, etc., MuSim aims to capture more subjective attributes. This means that the provenance of an association concept is important as well as the context.

1.2 Similarity as a Concept

In MuSim we treat musical associations as concepts rather than properties. Previous ontologies related to the domain of music (and ontologies in other domains) treat associations and similarity as properties. Using the Music Ontology we might say:

However we have no additional information about this similarity - is it based on acoustic features? chronological proximity? expert opinion? are the signals similar in terms of timbre? melodic content?

While it is entirely possible to make additional statements about this triple using a named graphs approach, MuSim provides a reification paradigm that allows for SPARQL queries that are more intuitive and more efficient in at least some triple store implementations (eg 4Store)

In MuSim we propose a concept-based approach to association. Similarity and association are concepts to be described and contextualized with supporting concepts and properties. This is illustrated in figure 2.

A graph visualization of how MuSim concepts are intended to be used. A similarity statement of type sim:Similarity is associated with an instance of sim:AssociationMethod which in turn leads to more information about the similarity derivation process

2. MuSim ontology at a glance

An alphabetical index of MuSim terms, by class (concepts) and by property (relationships, attributes), are given below. All the terms are hyper-linked to their detailed description for quick reference.

3. MuSim ontology overview

Instead of treating similarity or, to use a broader term, association as a property, we treat association as a class concept. This allows for easy reification of similarity statements. We introduce the class sim:Association and a sub-class sim:Similarity as the key concepts in our ontology. We then define the class sim:AssociationMethod for describing a method for determining similarity. By associating a similarity statement of type sim:Similarity with an instance of sim:AssociationMethod we are describing in what sense the elements involved in our statement are similar. We can attach additional provenance and/or transparency data to the sim:AssociationMethod as desired.

3.1. Simple Example

	@prefix mo <http://purl.org/ontology/mo/>
	@prefix sim <http://purl.org/ontology/similarity/>       
	@prefix foaf <http://xmlns.com/foaf/0.1/>	

	:track01 a mo:Track .  
	:track02 a mo:Track .  

	:me a foaf:Person .  

	:mySimilarity a
	  sim:Similarity ; 
	  sim:element :track01 ; 
	  sim:element :track02 ;
	  sim:weight "0.90" ; 
	  foaf:maker :me .

First we define two tracks using the corresponding Music Ontology concept mo:Track. The identifiers of these tracks can give entry points to additional information in other data sets (i.e. linking to dbpedia.org URIs or MusicBrainz identifiers). We define :mySimilarity as the actual similarity statement. The sim:element property is used to refer to the tracks involved in this similarity and the foaf:maker property refers to the agent which asserted this similarity. Also note we can assign a numerical weight value to the similarity using the sim:weight property.

Now we have a method for asserting a similarity statement and reifying that statement to some extent. However, in the above example we only know who is making the similarity statement, we do not know how or why.

Note that to specify a directed association we could use sim:subject and sim:object instead of sim:element. The use of sim:subject and sim:object implies a directed similarity relationship while the use of sim:element implies an undirected association. In a sense we are using the subject-predicate-object paradigm that is so familiar in RDF but the predicate is a concept instead of an object property. This makes our modeling reminiscent of that used in the rdf:Statement reification process with the rdf:predicate implied. However, a directed sim:Association does not inherently imply any additional triple while the rdf:Statement does imply a "simple" triple exists (causing a duplication problem among other problems). Also note that despite syntactic similarities, sim:subject is not a subclass of rdf:subject and sim:object is not a subclass of rdf:object and sim:Association is not a subclass of rdf:Statement.

3.2. Using sim:AssociationMethod for Provenance

We introduce the sim:AssocationMethod concept to identify the process used to derive a similarity statement. This enables some interesting functionality when consuming the associations data - a consumer application can elect to include only similarity statements that are derived by a particular process. This is discussed further in the SPARQL query examples section . For now let us consider the following N3 listing:

	@prefix mo <http://purl.org/ontology/mo/>
	@prefix sim <http://purl.org/ontology/similarity/>       
	@prefix foaf <http://xmlns.com/foaf/0.1/>

	:timbreSimilarityStatement
	  a sim:Similarity ;
	  sim:subject :track01 ;
	  sim:object :track02 ;
	  sim:weight "0.9" ;
	  sim:method :timbreBasedSimilarity .

	:timbreBasedSimilarity
	  a sim:AssociationMethod ;
	  foaf:maker :me ;

Here :timbreBasedSimilarity is the entity that describes our process for deriving similarity statements. Note that this entity is only described by two triples - its class type and a property for the creator.

By including an identifier for the similarity derivation process we enable the use of more advanced provenance frameworks. The sim:AssociationMethod can be considered a Process - some action or series of actions performed on or caused by artifacts and resulting in new artifacts. In the MuSim context artifacts are sim:Associations. With this simple mapping paradigm we can potentially plug MuSim into nearly any provenance framework including provenance the Open Provenance Model, the Provenir Ontology, the Provenance Vocabulary, or any other provenance framework that uses the concepts of processes and artifacts.

Note mappings to provenance ontologies are currently not made explicit. Explicit mappings might be included in the future perhaps based on the recommendations of the W3C Provenance Incubator Group.

We now have some level of provenance - at least an entry point to some given provenance framework, but we can also include some level of transparency by disclosing a association derivation workflow.

3.3. Workflow Graphs and Transparency

Now consider we have a workflow that describes a particular association derivation process. We can bind this workflow to an appropriate sim:AssociationMethod using the sim:workflow property.

	@prefix mo <http://purl.org/ontology/mo/>
	@prefix sim <http://purl.org/ontology/similarity/>       
	@prefix foaf <http://xmlns.com/foaf/0.1/>

	:timbreSimilarityStatement
	  a sim:Similarity ;
	  sim:element :track01 ;
	  sim:element :track02 ;
	  sim:weight "0.9" ;
	  sim:method :timbreBasedSimilarity .

	:timbreBasedSimilarity
	  a sim:AssociationMethod ;
	  foaf:maker :me ;
	  sim:workflow :algorithm .

	:algorithm = {
	{ { ?signal1 mo:published_as ?track01 .
	    ?signal1 sig:mfcc ?mfcc1 . 
	    ?mfcc1 sig:gaussian ?model1 } 
	      ctr:cc
	  { ?signal2 mo:published_as ?track02 .
	    ?signal2 sig:mfcc ?mfcc2 . 
	    ?mfcc2 sig:gaussian ?model2 } . 
	  (?model1 ?model2) sig:emd ?div .
	  ?div math:lessThan 0.2 } =>
	  { _:timbreSimilarityStatement
	      a sim:Similarity ;
	      sim:element ?track01 ;
	      sim:element ?track02 } 
	}

In the above example, :algorithm is a named graph that elucidates the process used for deriving this similarity statement. We use the N3-Tr syntax as described by Raimond in his thesis. Alternative workflow frameworks could be used as well. Additional details of specifying similarity derivation workflows are left to future work.

This :algorithm graph provides a disclosure of the algorithm used in the similarity derivation process. In this case, Mel-frequency cepstral coefficients (MFCCs) are extracted and Gaussian mixture models are created concurrently for the two signals, and an earth mover's distance is calculated between models. This is a method commonly used in audio-based signal analysis to derive some measure of timbre similarity. Depending on that distance, we output a similarity statement. If more details are needed about a particular computational step, e.g.~if we want to gather more information about the MFCC extraction step, we can look-up the corresponding web identifier, in this case sig:mfcc.

Various levels of transparency are achievable using the similarity ontology. This is illustrated in the following figure.

3.4. MuSim SPARQL Queries

Queries in this similarity ecosystem would be made using the SPARQL query language. The SPARQL specification is a W3C recommendation and the preferred method for querying RDF graphs. As mentioned before, the design of the Similarity Ontology allows for the construction of simple queries to retrieve similarity information. The following query retrieves artists similar to a target artist as stated by a specific trusted method:

	PREFIX sim: <http://purl.org/ontology/similarity/>	

	SELECT ?artists WHERE {
	  ?statement sim:method <http://trusted.method/uri> .
	  ?statement sim:element <http://target.artist/uri> .
	  ?statement sim:element ?artists .
	}

Notice we only have to include a triple pattern for our target resource, a triple pattern for our trusted agent, and a triple pattern to select the similar artists. Of course this is a very simple example and in real-world applications we include additional optional patterns and conjunctions for a more expressive query.

In an initialization step, an application could query available data sources to determine exactly what association methods and asserting agents are available. The application would use the following query:

The application could then filter through the results and, perhaps with some input from the end-user, decide which similarity agents to trust.

3.5. Implementations

4. Cross-reference for MuSim classes and properties

Class: sim:Association

URI: http://purl.org/ontology/similarity/Association

Association - An abstract class to define some association between things. Entities share an association if they are somehow inter-connected. Generally a directed association should have at lease one sim:subject property and one sim:object property or an undirected association should have at least two sim:element properties, however this is not a requirement and intentionally left out of the model.

sub-class-of:: owl:Thing
in-domain-of:: sim:element; sim:grounding; sim:method; sim:object; sim:subject; sim:weight; sim:distance
in-range-of:: sim:edge; sim:association
status:: testing