Some More Individual

My contributions to the LinkedBrainz project

zazi0815 — Fri, 29 Jul 2011 18:51:24 +0000

I worked over the last month on the LinkedBrainz project. I was responsible for continuing the mapping of the MusicBrainz Next Generation Schema (MBZ NGS) into appropriated descriptions that make use of various Semantic Web ontologies (especially the Music Ontology (MO)) that was initialised by kurtjx last year and slightly continued by barryn et al. This mapping is described with the help of the D2RQ mapping language and can be executed on a D2R Server (D2RS) instance.
During that time I created various new projects on GitHub or committed changes to existing ones. That’s why, I would like to give you an overview about the various projects and their main content in the following:

The Linked Brainz D2RS instance project includes:
- the D2RQ mapping description of the MBZ NGS to MO etc. mapping
- the Java libraries this D2RS instance depends on
- a wiki with LinkedBrainz-dataset-related information, e.g., its supported information services
- an issues list with open issues that were discovered during the development of the mapping
The LinkedBrainz-related D2R Translator classes project includes:

the LinkedBrainz-related D2R Translator classes that are necessary for the mapping
an issues list with open issues that are not resolved yet

The LinkedBrainz MBZ NGS to MO etc. mapping test cases project includes:
- the test cases for testing the MBZ NGS to MO etc. mapping
- a JavaDoc documenting the source code of these JUnit tests
- a script to execute all tests (excluding the Track-concept-related tests)
- log files of various test executions
- an issues list with open issues that are discovered during the development and execution of the tests
The following projects were also created during the development of the mapping and its tests:
- a Maven project of the D2R Server that powers the LinkedBrainz D2R instance
- a Maven project of D2RQ that powers the LinkedBrainz D2R instance (incl. some patches that are now included in the main D2RQ project as well, see here)
The following projects parts or project branches were also related during the development of the mapping and its tests:
- a list of various Music-Ontology-related issues which are mainly dealing with concepts and/or properties that are not implement in the Music Ontology yet
- an attempt to upgrade the Jena and ARQ dependencies to the most recent ones
  - this attempt didn’t fully succeeded yet (see here)

The result of my work so far is that I couldn’t finish the whole mapping of MBZ NGS into appropriated Semantic Web ontology terms. There are still many mappings not available for the link types of the MBZ NGS Advanced Relationships and some where appropriated concepts and/or properties did not exist yet (see above).
Finally, it would be fine to implement a vendor-independent mapping that is based on the R2RML mapping language.

PS: Since the test suite is based on tests that compare the results of SQL queries against the results of SPARQL queries, it can be applied on any other MBZ NGS to MO etc. mapping as well (equivalents to specific D2RQ Translator classes must implement the D2RQ Translator class interface)

Semantic Federation of Music and Music-Related Information for Establishing a Personal Music Knowledge Base

zazi0815 — Sun, 17 Jul 2011 19:13:13 +0000

Finally, I finished my studies in May 2011. I’m now a degreed something (I would prefer the name Philosphical Engineer or Data Engineer or something like that ). Since I’m still struggling with formatting my thesis into HTML (LaTeX to HTML transformation doesn’t seem to an easy task when utilising quite customized macros – anyone woh can help me realizing this task is more than welcome).
So here we go with the PDF version of my thesis and the HTML-based presentation slides* of my defence talk.

Abstract:

Music is perceived and described very subjectively by every individual. Nowadays, people often get lost in their steadily growing, multi-placed, digital music collection. Existing music player and management applications get in trouble when dealing with poor metadata that is predominant in personal music collections. There are several music information services available that assist users by providing tools for precisely organising their music collection, or for presenting them new insights into their own music library and listening habits. However, it is still not the case that music consumers can seamlessly interact with all these auxiliary services directly from the place where they access their music individually.
To profit from the manifold music and music-related knowledge that is or can be available via various information services, this information has to be gathered up, semantically federated, and integrated into a uniform knowledge base that can personalised represent this data in an appropriate visualisation to the users. This personalised semantic aggregation of music metadata from several sources is the gist of this thesis. The outlined solution particularly concentrates on users’ needs regarding music collection management which can strongly alternate between single human beings.
The author’s proposal, the personal music knowledge base (PMKB), consists of a client-server architecture with uniform communication endpoints and an ontological knowledge representation model format that is able to represent the versatile information of its use cases. The PMKB concept is appropriate to cover the complete information flow life cycle, including the processes of user account initialisation, information service choice, individual information extraction, and proactive update notification.
The PMKB implementation makes use of SemanticWeb technologies. Particularly the knowledge representation part of the PMKB vision is explained in this work. Several new Semantic Web ontologies are defined or existing ones are massively modified to meet the requirements of a personalised semantic federation of music and music-related data for managing personal music collections. The outcome is, amongst others,

a new vocabulary for describing the play back domain,

another one for representing information service categorisations and quality ratings, and

one that unites the beneficial parts of the existing advanced user modelling ontologies.

The introduced vocabularies can be perfectly utilised in conjunction with the existing Music Ontology framework. Some RDFizers that also make use of the outlined ontologies in their mapping definitions, illustrate the fitness in practise of these specifications.
A social evaluation method is applied to carry out an examination dealing with the reutilisation, application and feedback of the vocabularies that are explained in this work. This analysis shows that it is a good practise to properly publish Semantic Web ontologies with the help of some Linked Data principles and further basic SEO techniques to easily reach the searching audience, to avoid duplicates of such KR specifications, and, last but not least, to directly establish a “shared understanding”. Due to their project-independence, the proposed vocabularies can be deployed in every knowledge representation model that needs their knowledge representation capacities.
This thesis added its value to make the vision of a personal music knowledge base come true.

Have fun!

*) best view with Firefox 4.x+, full-screen mode on, and Univers font family installed

PS: the HTML-based presentation slides are based on an extended version of the Slidy template

Musical Characteristics Analysis

zazi0815 — Fri, 11 Mar 2011 12:31:07 +0000

This is a follow-up post of the recently published one that introduced a categorisation of musical characteristics.

Even the process of feature extraction and derivation from audio signals is a rather complex one. The graphic above illustrates an abstraction of the main tasks that are necessary to gain from given audio signals compact descriptions that are known as musical fingerprints. They should ideally act as a robust and correct song identification mechanism and be applicable for a very fast song recognition. That is why, they have to be efficient computable and compact as possible (see [1]). Fortunately, the whole audio signal analysis process can be outsourced and various music information services provide different functionalities to support this task, e.g., Echo Nest or Canoris.

A full-fledged work flow of musical characteristics analysis includes a music context data extraction process, besides an audio signal analysis task to retrieve music content data. Thereby, a metadata enhancement task makes use of further information services, instead of only relying on information that can be gained from a music document (see the graphic above). It is important to note that the processes of classification, categorisation and similarity calculations should be driven by user profiles to be adaptable [2]. Finally, fuzzy and abstract feature descriptions are necessary to enable an intuitive handling with the music knowledge base.
Please have a look at my bachelor-like thesis [2] to get a deeper insight of the background of music content and context data, and the not trivial extraction and derivation process of musical characteristics. Even this whole analysis process can be outsourced (as needed) to external music information services, e.g., Echo Nest.
A PDF version of the audio signal feature extraction and derivation figure can be found here and one of the musical characteristics analysis figure there. These graphics are freely usable and sharable under the Creative Common Attribution 3.0 Unported license.

[1] Cano, Pedro; “Content-based Audio Search: From Fingerprinting to Semantic Audio
Retrieval”; PhD thesis; Technology Department of Pompeu Fabra University,
Barcelona; 2007
[2] Ferris, Bob; “Musical and Music Related Metadata and Features for Administration of Private Music Collections”; smiy.org; 2010

Categories of Musical Characteristics

zazi0815 — Sat, 26 Feb 2011 11:01:52 +0000

The phenomenon of music in its full range can be described by manifold concepts and subjective perceived features. In a nutshell these are musical characteristics. Their origins are varied from sciences i.e., physics, psychoacoustics, music theory, and musicology, or they are established by a community or culture.
Generally, musical characteristics are highly versatile and can be arranged in different levels and sub categories. The classification above is taking its cue from the conceptual framework Musical Audio Mining (MAMI; see [1]). It is a translation of the categorisation that was introduced and fully explained in my bachelor-like thesis. It has three main types. These are basic audio signal features, derived audio signal features and taxonomies. Classifications of the latter ones are derived from features of the former ones. Besides, entities of taxonomies, e.g., music genre taxonomies, can be evolved from music context data or a combination of both main types of music description.
A PDF version of that figure can be found here. This graphic is freely usable and sharable under the Creative Common Attribution 3.0 Unported license.

[1] Lesaffre, Micheline; “Music Information Retrieval – Conceptual Framework, Annotation and User Behaviour”; PhD thesis; Faculty of Arts and Philosophy, Department of Art, Music and Theatre Sciences Ghent University; 2006

A generalisation of the Linked Data publishing guideline

zazi0815 — Thu, 17 Feb 2011 16:37:12 +0000

Initially (in summer 2006), Tim Berners Lee composed the Linked Data publishing guideline to address shortcomings of predominant data providing practices in the Web and to promote the benefits of utilizing Semantic Web knowledge representation models for that issue. Later, people started realizing the independency of these principles to concrete applied technologies, i.e., the Linked Data publishing guideline is generally independent from Semantic Web technologies. This movement is especially propagated by Kingsley Idehen (see [1]).
The Linked Data publishing guideline addresses the following five main principles. Whereby, the fifth one is a recently made, optional addition that was suggested by Matthew Rowe (see [2]).

Use a name reference mechanism for resource identification, e.g., URIs (cf. the first interface constraint of the REST architectural style).
Use an information resource delivering mechanism on top of that name reference mechanism, e.g., a URI scheme, for example, HTTP URIs, to enable the transfer of a document that contains at least the information resource to a requested resource identifier (cf. the second interface constraint of the REST architectural style*).
Use a resource description mechanism to facilitate the expression of knowledge (assertions) regarding the denoted resource, e.g., RDF (cf. the forth interface constraint of the REST architectural style).
Provide a resource connection mechanism to permit the embedding of links. They refer to other resources to establish meaningful (unambiguously as possible) interpretations of a received information resource. This enforces knowledge exploration, e.g., via the HTTP Link header field, if, for instance, the specification of the media type does not make link embedding in the representation possible (cf. “follow your nose” and the fifth interface constraint of the REST architectural style).
Provide an information resource modification mechanism by allowing (optionally) the transfer of (a) modification(s) of received content by using the resource identifier of the request, e.g., changes are entered in a (HTML) form and sent to the server by applying the HTTP PATCH method (cf. the third interface constraint of the REST architectural style).

Thereby, especially the last principle directs into a read and write enabled Linked Data information space scenario (see [3]). A good overview of relevant specifications for Linked Data in the context of the Semantic Web can be found at linkeddata-specs.info.

*) Note, this constraint was later explicitly phrased, see the referenced presentation.

[1] Idehen, Kingsley; “What is Linked Data, really?”; openlinksw.com; 2011
[2] Rowe, Matthew; “A Proposed 5th Rule/Principle for Linked Data: Push”; matthew-rowe.com; 2010
[3] Berners-Lee, Tim; “Read-Write Linked Data”; w3.org; 2010

Further related resources:

Ferris, Bob; “The common, layered Semantic Web technology stack”; smiy.org; 2011
Ferris, Bob; “On Resources, Information Resources and Documents”; smiy.org; 2010

The common, layered Semantic Web technology stack

zazi0815 — Mon, 10 Jan 2011 19:23:38 +0000

Here is a visualization of the common, layered Semantic Web technology stack. This graphic is a modified version of the Semantic Web technology stack visualization created by Benjamin Nowack. This figure is freely usable and sharable under the Creative Common Attribution 3.0 Unported license.
Here are some references to get into some parts of the different layers:

The Web Platform: URI (Uniform Resource Identifier)/ IRI (Internationalized Resource Identifier), HTTP (HyperText Transfer Protocol) and HTML (HyperText Markup Language) that build together the basis for the hypertext Web; Linked Data
Syntax: N3 (Notation 3)/ Turtle (Terse RDF Triple Language), RDFa, XML (Extensible Markup Language) and JSON (JavaScript Object Notation)
Knowledge Representation Structure (a simple knowledge representation language): RDF (Resource Description Framework) Model
Semantics (advanced knowledge representation languages): RDFS (RDF Schema), OWL (Web Ontology Language)
Rules: RIF (Rule Interchange Format)
Query: SPARQL
Security: WebID, CORS (Cross-Origin Resource Sharing)
Proof: Named Graphs, Provenance XG
Trust: WebID, Provenance XG, CORS (Cross-Origin Resource Sharing)
Applications: Social Web, LOD (Linked Open Data) Cloud

Ontologies and Vocabularies in the PMKB* space

zazi0815 — Mon, 20 Dec 2010 19:21:35 +0000

It’s time to present an overview of applied, related, modified and created ontologies and vocabularies I’m currently working with. The graphic above shows an overview of applied ontologies and vocabularies in the knowledge representation model of the personal music knowledge base (PMKB). One can see the reutilisation of existing Semantic Web ontologies in new ones and furthermore, also their application in other new Semantic Web ontologies. A link from one vocabulary to another one was created, when at least one sub class, sub property, domain or range relation to another vocabulary exists. Some existing Semantic Web ontologies were also modified during the development process for required universals for the knowledge representation model of the personal music knowledge base.
In the following are reference to the specifications of the mentioned ontologies, vocabularies and schemata.

existing vocabularies:

modified vocabularies:

new vocabularies:

PS: sorry for the overlaying arcs, unfortunately I did not get a better design managed with Inkscape (any helpful hints are very welcome)

*) PMKB is the acronym for personal music knowledge base the project I’m currently working on

The Cognitive Characteristics Ontology

zazi0815 — Tue, 19 Oct 2010 10:57:42 +0000

Hello everybody,

it’s time to announce the Cognitive Characteristics Ontology

Currently, several approaches regarding interests representation exist in form of separate Semantic Web Ontologies, e.g. the Weighted Interest Vocabulary, the e-foaf:interest Vocabulary or the Interest Mining Ontology. Each of the mentioned approaches is somehow aligned to the interests modelling concept of the FOAF Vocabulary.
Due to that reason, I decided to merge all these interest related ontologies under one hood , model some concepts properly and add useful extensions. This ontology alignment process is strongly influenced by the outcome of the User (weighted) Interests Ontology working group from Hypios VoCamp Paris 2010. The result of this task was the Weighted Interests Vocabulary 0.5. However, the range of that ontology is still a bit limited, because it provides “only” basic concepts and properties for describing preferences (interests) within contexts, their temporal dynamics and their origin.
That’s why, I built the Cognitive Characteristics Ontology on top of the latest revision of the Weighted Interests Vocabulary to broaden the scope to be able to model cognitive patterns. That means all concepts and properties are imported from this ontology. Some of them are also redefined and renamed to broaden their meaning. Furthermore, the Cognitive Characteristics Ontology is inspired by the Unified User Context Model, the General User Model Ontology, the User Modelling for Information Retrieval Language (UMIRL) and all their fundamental sources, and finally, the discussions on the FOAF developers mailing list.

The Cognitive Characteristics Ontology includes two opportunities to model cognitive patterns. The first one is the representation of cognitive characteristics by using the semantic relation cco:cognitive_characteristic or better its more specialised sub properties (see the graphic above) to associate the topics of the cognitive patterns to the users. The second opportunity is the
object-oriented context reification of cco:cognitive_characteristic, cco:CognitiveCharacteristic, which is a general multiple purpose cognitive characteristic concept to describe cognitive patterns more in detail for a specific user or user group.
As one can see in the graphic above, the specialised sub properties of cco:cognitive_characteristic, the cognitive patterns, currently are

interest (cco:interest), that means, a certain area of interest or preference, which is equivalent to foaf:topic_interest,
compentence (cco:competence), that means, the compentence to (be able to) do or know something or
setting (cco:setting), often regarding a specific environment, e.g. an application.

One can also refine the semantic relation of a competence association by using the sub properties of cco:competence, which are currently:

cco:skill: the ability or skill to (be able to) do something, e.g. to walk, to play the piano or to work in a team
cco:expertise: the knowledge or expertise in a certain domain or a specific topic, e.g. football, programming languages or music
cco:belief: an uncertain relation for competence representation, that means beliefs, persuasions or opinions, which can also be misconceptions

One can see the second opportunity to model cognitive patterns, cco:CognitiveCharacteristic in the graphic above (or here for an extended version). This concept can be used to associate any foaf:Agent instance to (a) cco:CognitiveCharacteristic instance(s) with help of the properties cco:habit and cco:agent. The topics of a cco:CognitiveCharacteristic instance are related to it by using the property cco:topic, so that a property chain of cco:habit and cco:topic will also direct to topics of a cognitive pattern of an user or user group. That means, a statement that is modelled with the simple semantic relation approach based on cco:cognitive_characteristic can also be represented by an instance of cco:CognitiveCharacteristic, which has a cco:agent or cco:habit, a cco:topic and a cco:characteristic relation. The last property in this row is used to associate the applied cognitive pattern relation (sub properties of cco:cognitive_characteristic).
Different statistics can be made on cognitive characteristics. These are currently:

cco:overall_weight, which reflects the overall interest in a topic and should be different from the actual weight (associated by the property wo:weight) of a cognitive characteristic
cco:longest_duration, which is the longest continuous interval of attention for a cognitive pattern
cco:ultimative_duration, which is the overall duration of attention for a cognitive pattern

Besides these statistics, one can also associate a concrete activity (by using the property cco:activity), to differentiate e.g. between football playing (topic = football; activity = playing) and football watching (topic = football; activity = watching), and further statistical items (by using the property cco:statistical_item) to a cognitive pattern description, which is itself also a sub class of scovo:Item.
It is also important, to be able to describe dynamics of a cognitive characteristic. In the Cognitive Characteristics Ontology they can be described with help of the cco:CharacteristicDynamics concept, which is a sub class of wo:Weight, and can be related to a cco:CognitiveCharacteristic instance by using the property cco:characteristic_dynamics. Thereby, one can relate

concrete appear times (time instants or intervals, by using the property cco:appear_time), when a cognitive pattern gets attention by someone, or
an evidence description (by using the property cco:evidence), where this characteristic or dynamics was derived from.

to a cco:CognitiveCharacteristic or cco:CharacteristicDynamics instance.
Below are two use case examples modelled with help of the Cognitive Characteristics Ontology. The first one describes a part of an user profile as it can be taken from an user account of a personal music knowledge base and the second one an user profile example with different cognitive characteristics of the same topic.

@prefix foaf: . @prefix cco: . @prefix wo: . @prefix days: . @prefix tl: . @prefix xsd: . @prefix ex: . @prefix rdf: . @prefix rdfs: . @prefix owl: . @prefix dc: . @prefix cv: . @prefix cvbase: . @prefix countries: . @prefix sim: . @prefix ao: . ex:APerson a foaf:Person , cv:Person ; foaf:name "John White" ; foaf:birthday "1974-07-09"^^xsd:date ; foaf:gender "male" ; cv:hasCitizenship countries:US ; cco:skill ; cco:skill ; cco:expertise ; cco:interest ; cco:interest ; cco:interest ; cco:interest ; cco:interest ; cco:interest ; cco:interest ; cco:interest ex:IdiosyncraticGenre1 ; cco:interest ex:IdiosyncraticGenre2 ; cco:habit [ a cco:CognitiveCharacteristic ; cco:topic ; cco:characteristic cco:skill ; wo:weight [ a wo:Weight ; wo:weight_value 6.0 ; wo:scale ex:AScale ] ; cco:activity ] ; cco:habit [ a cco:CognitiveCharacteristic ; cco:topic ; cco:characteristic cco:skill ; wo:weight [ a wo:Weight ; wo:weight_value 7.0 ; wo:scale ex:AScale ] ; cco:activity ] ; cco:habit [ a cco:CognitiveCharacteristic ; cco:topic ; cco:characteristic cco:expertise ; wo:weight [ a wo:Weight ; wo:weight_value 0.0 ; wo:scale ex:AScale ] ; ] ; cco:habit [ a cco:CognitiveCharacteristic ; cco:topic ; cco:characteristic cco:interest ; wo:weight [ a wo:Weight ; wo:weight_value 7.0 ; wo:scale ex:AScale ] ; ] ; cco:habit [ a cco:CognitiveCharacteristic ; cco:topic ; cco:characteristic cco:interest ; wo:weight [ a wo:Weight ; wo:weight_value 9.0 ; wo:scale ex:AScale ] ; ] ; cco:habit [ a cco:CognitiveCharacteristic ; cco:topic ; cco:characteristic cco:interest ; wo:weight [ a wo:Weight ; wo:weight_value 5.0 ; wo:scale ex:AScale ] ; ] ; cco:habit [ a cco:CognitiveCharacteristic ; cco:topic ; cco:characteristic cco:interest ; wo:weight [ a wo:Weight ; wo:weight_value 8.0 ; wo:scale ex:AScale ] ; ] ; cco:habit [ a cco:CognitiveCharacteristic ; cco:topic ex:IdiosyncraticGenre2 ; cco:characteristic cco:interest ; wo:weight [ a wo:Weight ; wo:weight_value 7.0 ; wo:scale ex:AScale ] ; cco:appear_time [ a days:WeekdayInterval ; dc:title "bedtime" ; tl:at "23:00:00"^^xsd:time ] ; ] . ex:ACV a cv:CV ; cv:aboutPerson ex:APerson ; cv:hasEducation [ a cv:Education ; cv:degreeType cvbase:EduMaster ] ; cv:hasWorkHistory ex:AWorkHistory . ex:AWorkHistory a cv:WorkHistory ; cv:careerLevel cvbase:Student . ex:tempo a rdf:Property , owl:DatatypeProperty ; rdfs:range xsd:string ; rdfs:subPropertyOf ao:context . ex:IdiosyncraticGenre1 a sim:Association ; dc:title "happy music" ; ao:genre ; ex:tempo "allegro" ; ao:mood "happy" . ex:IdiosyncraticGenre2 a sim:Association ; dc:title "romantic music" ; ex:tempo "largo" . ex:AScale a wo:Scale ; wo:min_weight 0.0 ; wo:max_weight 9.0 ; wo:step_size 1.0 .

This example above shows a part of an user profile as it can be taken from an user account of a personal music knowledge base. It is inspired by an example that was originally modelled with UMIRL (see here) and now remodelled with more expressiveness with help of the Cognitive Characteristics Ontology. The user profile is from the person John White, who can play the piano and sing by having no education in music. Furthermore, he is interested in several music genres, the music artist Wolfgang Amadeus Mozart, the music group the Beatles, the music song “Yesterday” from the Beatles and some self-defined idiosyncratic music genres.
At the beginning, all cognitive patterns of this user are described by simple semantic relations, which are sub properties of cco:cognitive_characteristic. Thereby, the most of the topics of the cognitive characteristic relations are information resources from the information service DBPedia and one topic is a information resource from DBTune. Afterwards, some of these shortcut relations are described more in detail with help of cco:CognitiveCharacteristic instances.
Each of these cognitive characteristic descriptions is related to a weighting with a different weight value (related by wo:weight_value) and the same scale (related by wo:scale). Due to these weightings, we can conclude that John White can sing and play the piano quite good. However, he has no knowledge in musical foundations. Furthermore, a cco:CognitiveCharacteristic instance is associated with a topic (by cco:topic) of a shortcut relation and a property (by cco:characteristic) of such a relation. Besides these information some of them are also related with an activity (associated by cco:activity), which are information resources from OpenCyc (playing a musical instrument) or DBPedia (singing).
This user profile example includes especially detailed descriptions of John White’s interest in specific music genres. Thereby, we can conclude (besides other things) that he is a big fan of Blues and Rock music and quite interested in romantic music (ex:IdiosyncraticGenre2). The last music genre is defined as music context, which he prefers weekdays (represented by days:WeekdayInterval) at “bedtime” (ca. 11 pm). This idiosyncratic genre is itself defined as a sim:Association instance, which is titled as “romantic music” and should be very slow (largo, associated by ex:tempo as sub property of ao:context).

@prefix foaf: . @prefix cco: . @prefix wo: . @prefix ex: . ex:APerson a foaf:Person ; foaf:name "John Wayne" ; cco:skill ; cco:expertise ; cco:interest ; cco:habit [ a cco:CognitiveCharacteristic ; cco:topic ; cco:characteristic cco:skill ; wo:weight [ a wo:Weight ; wo:weight_value 6.0 ; wo:scale ex:AScale ] ; cco:activity ] ; cco:habit [ a cco:CognitiveCharacteristic ; cco:topic ; cco:characteristic cco:expertise ; wo:weight [ a wo:Weight ; wo:weight_value 7.0 ; wo:scale ex:AScale ] ; ] ; cco:habit [ a cco:CognitiveCharacteristic ; cco:topic ; cco:characteristic cco:interest ; wo:weight [ a wo:Weight ; wo:weight_value 5.0 ; wo:scale ex:AScale ] ; cco:activity ] . ex:AScale a wo:Scale ; wo:min_weight 0.0 ; wo:max_weight 9.0 ; wo:step_size 1.0 .

This user profile example above, with different cognitive characteristics of the same topic, represents the person John Wayne, who has tree different cognitive patterns – a skill (cco:skill), an expertise (cco:expertise) and an interest (cco:interest) – with the topic soccer. At the beginning, each semantic relation is modelled as shortcut relation. Afterwards, follow more detailed descriptions of these three cognitive characteristics, which are associated to John Wayne by using the property cco:habit. Each of these cco:CogntiveCharacteristic instances include, besides the basis information of the shortcut relations, also a weight description and two of them, furthermore, an activity relation (associated by cco:activity).
So that a reasoning engine is now not only able to automatically infer the knowledge from the shortcut relations now, but rather then also from the reification class instances. That means, one can conclude that John Wayne

can play soccer quite moderate,
has a quite good knowledge about the topic soccer and
and is moderatly interested in watching soccer.

Such a modelling has the advantage that one can talk about one and the same topic, independently of the activities that are related to cognitive pattern descriptions of a person. This is possible, because activity, cognitive characteristic and topic have their own, separate dimension.
As one can see the by the two use case examples above, the expressivity of the Cognitive Characteristics Ontology is manifold. More examples are available in the examples section of the specification documention.
I would like to thank very much the creators of the different interest ontologies, where this multiple purpose cognitive charateristics ontology is based on. That means, Dan Brickley, Dave Reynolds, Libby Miller, Toby Inkster, Yi Zeng, Yan Wang, Danica Damljanovic, Zhisheng Huang, Alexandre Passant, Sheila Kinsella and John Breslin. Furthermore, the creators of the Unified User Context Model, of the General User Model Ontology, of the User Modelling for Information Retrieval Language and all their fundamental sources, and finally, the people from the FOAF developers mailing list, especially Nima Dokoohaki. Please feel free to reuse and extend the Cognitive Characteristics Ontology also for your own projects (let me know your use cases ). Comments, suggestions and critics are also very welcome.

Cheers,

Bob

The Recommendation Ontology

zazi0815 — Sat, 07 Aug 2010 11:05:32 +0000

Hello everybody,

today I like to present the Recommendation Ontology, which is an ontology for modeling high level recommendations on/ for the Semantic Web. Thereby, the ontology hook up parts of the Similarity Ontology, DCMI Metadata Terms, the Association Ontology and the Ordered List Ontology.

The graphic above illustrates the core of the Recommendation Ontology, the rec:Recommendation concept (see also here, for an extended view, and here, for an extended graph with relations, of this concept). A rec:Recommendation instance can consist of

an item or agent relation (rec:recommendation or its inverse property rec:for) to associate the resource, for which the recommendation was made
an recommender relation (rec:recommender or its inverse property rec:recommends) to associate the instance, which provided or calculated the recommendation, e.g. an is:InfoService instance
recommendation object relations (rec:recommendation_object or its inverse property rec:recommended_in) to associate appropriated objects to the recommendation subject
recommendation audience relations (rec:recommendation_audience) to associate groups or stereotypes, which are probably appropriated as target group for this recommendation.

Since rec:Recommendation is a sub class of ao:LikeableAssociation, it is also possible to like (ao:likeminded), rate (rev:rating) or give a feedback (rev:Feedback) to a recommendation. Furthermore, one can also relate detailed association (sim:Association based) or similarity statements (sim:Similarity based) to a recommendation by using the property ao:included_association.

As an extension of rec:Recommendation, we built the rec:RankedRecommendation concept to enable also ordered (ranked) recommendations at a high level. The graphic above illustrates this concept as graph with relations (see also here, for an extended graph view). rec:RankedRecommendation is not only a sub class of rec:Recommendation, furthermore, it is also a sub class of olo:OrderedList, which enables all features of an ordered list also to this concept. Following this design, a rec:ranked_recommendation_object is not only a sub property of rec:recommendation_object, but also a sub property of olo:slot. That means the recommendation objects are now related by using the property olo:item.
Below are two examples of use cases modelled with help of the Recommendation Ontology. The first one describes an extended music track recommendation and the second one a simple music track recommendation example.

@prefix rec: . @prefix ex: . @prefix olo: . @prefix isi: . @prefix ao: . @prefix sim: . @prefix is: . @prefix dbtune: . dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 rec:recommendation ex:AMusicRecommendation . ex:AMusicRecommendation a rec:RankedRecommendation ; rec:recommender isi:lastfm ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; rec:ranked_recommendation_object [ a olo:Slot ; olo:item dbtune:097c362d-72b7-4a53-96e2-d9ff02f8be1f ; olo:index 1 ] ; rec:ranked_recommendation_object [ a olo:Slot ; olo:item dbtune:161d35d9-3e31-41e9-8392-cf5d2c03b31d ; olo:index 2 ] ; rec:ranked_recommendation_object [ a olo:Slot ; olo:item dbtune:093c1742-ebda-45cd-a50c-734e5d92e7f2 ; olo:index 3 ] ; rec:ranked_recommendation_object [ a olo:Slot ; olo:item dbtune:0a208327-525a-429b-8e79-51669bfb81f7 ; olo:index 4 ] ; rec:ranked_recommendation_object [ a olo:Slot ; olo:item dbtune:0161855d-0b98-4f2d-b2ab-446dbd8d6759 ; olo:index 5 ] ; rec:ranked_recommendation_object [ a olo:Slot ; olo:item dbtune:014f2510-e653-43e9-862a-880ac6388bb1 ; olo:index 6 ] ; rec:ranked_recommendation_object [ a olo:Slot ; olo:item dbtune:0ab210b0-18c6-4c52-aee7-78f6012b9192 ; olo:index 7 ] ; rec:ranked_recommendation_object [ a olo:Slot ; olo:item dbtune:027326ef-1455-48c9-8543-ac908eb71925 ; olo:index 8 ] ; rec:ranked_recommendation_object [ a olo:Slot ; olo:item dbtune:04dc3d0b-dff4-41a0-8bf3-12b4b34460a6 ; olo:index 9 ] ; rec:ranked_recommendation_object [ a olo:Slot ; olo:item dbtune:0348eea1-8178-4dc1-8a37-d09b5897ace2 ; olo:index 10 ] ; ao:included_association ex:SimAssociation01 ; ao:included_association ex:SimAssociation02 ; ao:included_association ex:SimAssociation03 ; ao:included_association ex:SimAssociation04 ; ao:included_association ex:SimAssociation05 ; ao:included_association ex:SimAssociation06 ; ao:included_association ex:SimAssociation07 ; ao:included_association ex:SimAssociation08 ; ao:included_association ex:SimAssociation09 ; ao:included_association ex:SimAssociation10 . ex:lfmTrackSimilarity a sim:AssociationMethod ; is:info_service isi:lastfm . ex:Association01 a sim:Similarity ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; sim:object dbtune:097c362d-72b7-4a53-96e2-d9ff02f8be1f ; sim:weight 1.0 ; sim:method ex:lfmTrackSimilarity . ex:Association02 a sim:Similarity ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; sim:object dbtune:161d35d9-3e31-41e9-8392-cf5d2c03b31d ; sim:weight 0.968842 ; sim:method ex:lfmTrackSimilarity . ex:Association03 a sim:Similarity ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; sim:object dbtune:093c1742-ebda-45cd-a50c-734e5d92e7f2 ; sim:weight 0.547951 ; sim:method ex:lfmTrackSimilarity . ex:Association04 a sim:Similarity ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; sim:object dbtune:0a208327-525a-429b-8e79-51669bfb81f7 ; sim:weight 0.449539 ; sim:method ex:lfmTrackSimilarity . ex:Association05 a sim:Similarity ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; sim:object dbtune:0161855d-0b98-4f2d-b2ab-446dbd8d6759 ; sim:weight 0.401746 ; sim:method ex:lfmTrackSimilarity . ex:Association06 a sim:Similarity ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; sim:object dbtune:014f2510-e653-43e9-862a-880ac6388bb1 ; sim:weight 0.36673 ; sim:method ex:lfmTrackSimilarity . ex:Association07 a sim:Similarity ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; sim:object dbtune:0ab210b0-18c6-4c52-aee7-78f6012b9192 ; sim:weight 0.36142 ; sim:method ex:lfmTrackSimilarity . ex:Association08 a sim:Similarity ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; sim:object dbtune:027326ef-1455-48c9-8543-ac908eb71925 ; sim:weight 0.351277 ; sim:method ex:lfmTrackSimilarity . ex:Association09 a sim:Similarity ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; sim:object dbtune:04dc3d0b-dff4-41a0-8bf3-12b4b34460a6 ; sim:weight 0.350151 ; sim:method ex:lfmTrackSimilarity . ex:Association10 a sim:Similarity ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; sim:object dbtune:0348eea1-8178-4dc1-8a37-d09b5897ace2 ; sim:weight 0.336997 ; sim:method ex:lfmTrackSimilarity .

This RDF/Turtle representation shows an extended music track recommendation modeled as rec:RankedRecommendation instance. It is based on the music track recommendations of James Brown’s “Get Up (I Feel Like Being a) Sex Machine” from Last.fm. Hence, the subject of the rec:recommendation relation is a resolvable URI to a description of James Brown’s “Get Up (I Feel Like Being a) Sex Machine” at MusicBrainz, modeled and represented as Semantic Graph and provided by DBTune.
Since a rec:RankedRecommendation is a sub class of rec:Recommendation and olo:OrderedList, it can also make use of ordered list features. That means, this
enables the opportunity to also provide an ordered (/ranked) list of recommendation objects (related by rec:ranked_recommendation_object), by hiding the details of their ranking features on this level. These details are provided by further association statements (here sim:Similarity) related by using the ao:included_association property.
Each slot item (related by olo:item) is also a music track description at MusicBrainz, modeled and represented as Semantic Graph and provided by DBTune. Furthermore, each similarity statement (sim:Similarity) includes

the seed music track (related by sim:subject), on which this similarity calculation is based on,
the other music track (related by sim:object),
the weight of the similarity (related by sim:weight) and
the association (here similarity) method (related by sim:method) of the similarity calculation.

This association method (sim:AssociationMethod) can not be further specified here, because it is based on a proprietary algorithm from Last.fm. Therefore, the complete recommendation (related by rec:recommender) and also the association method itself
(related by is:info_service) is associated to the Information Service Last.fm.

@prefix rec: . @prefix ex: . @prefix isi: . @prefix sim: . @prefix is: . @prefix foaf: . @prefix dbtune: . ex:AMusicRecommendation a rec:Recommendation ; rec:for dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; rec:recommender isi:lastfm ; rec:recommendation_audience ex:FunkyPeople ; sim:subject dbtune:008e72df-6469-4557-8b5b-c54c3285fbd3 ; rec:recommendation_object dbtune:097c362d-72b7-4a53-96e2-d9ff02f8be1f ; rec:recommendation_object dbtune:161d35d9-3e31-41e9-8392-cf5d2c03b31d ; rec:recommendation_object dbtune:093c1742-ebda-45cd-a50c-734e5d92e7f2 ; rec:recommendation_object dbtune:0a208327-525a-429b-8e79-51669bfb81f7 ; rec:recommendation_object dbtune:0161855d-0b98-4f2d-b2ab-446dbd8d6759 ; rec:recommendation_object dbtune:014f2510-e653-43e9-862a-880ac6388bb1 ; rec:recommendation_object dbtune:0ab210b0-18c6-4c52-aee7-78f6012b9192 ; rec:recommendation_object dbtune:027326ef-1455-48c9-8543-ac908eb71925 ; rec:recommendation_object dbtune:04dc3d0b-dff4-41a0-8bf3-12b4b34460a6 ; rec:recommendation_object dbtune:0348eea1-8178-4dc1-8a37-d09b5897ace2 ; sim:method ex:lfmTrackSimilarity . ex:lfmTrackSimilarity a sim:AssociationMethod ; is:info_service isi:lastfm . ex:FunkyPeople a foaf:Group .

This RDF/Turle representation is a simplified example from the extended music track recommendation example above. It is simply stripped down to its high level recommendation. The target, where the recommendation is for, is now related by the inverse property of rec:recommendation, rec:for. Furthermore, it includes a fictional audience group (ex:FunkyPeople), which is related by the property rec:recommendation_audience. Finally, the recommendation objects are now simply related by the property rec:recommendation_object. Of course, this doesn’t include the ranking, it is now an unordered list. However, it still includes the relation to its similarity method (ex:lfmTrackSimilarity).

The Recommendation Ontology and the illustrated examples above demonstrates the reutilization, specialization and application of concepts of existing ontologies. I like to invite you to create further, more specialized concepts and properties, which are based on the introduced ontologies, or further examples, which make use of the Recommendation Ontology, e.g. suggested items from Amazon, which are maybe also modeled with help of the GoodRelations vocabulary.

I would like to thank very much the whole Music Ontology Specification mailing list group to help to establish this multiple purpose recommendation ontology and especially Kurt Jacobson for providing everytime new input and ideas. Please feel free to reuse and extend the Recommendation Ontology also for your own projects (let me know your use cases ). Comments, suggestions and critics are also very welcome.

Cheers,

Bob

The Play Back Ontology

zazi0815 — Tue, 27 Jul 2010 10:09:26 +0000

Hello everybody,

today I like to present the Play Back Ontology, whose use cases are trying to combine and extend the previous announced ontologies (Ordered List Ontology, Counter Ontology and Association Ontology) and of course further ontologies (e.g. Music Ontology, Similarity Ontology, DCMI Metadata Terms, e.g. the Bibliographic Ontology or the Functional Requirements for Bibliographic Records Vocabulary), which are needed to model them and for ontology alignment. Therefore, the Play Back Ontology provides basic concepts and properties for modelling knowledge representations that are related to the play back domain, e.g. a playlist, play back and skip counter, on/ for the Semantic Web.

The play back domain is a subset of the media domain. It deals with playing back some media, e.g. videos, music tracks or slideshows, and how used media can be structured or organized.

On the basis of this definition the objects that are included into this domain are media objects. That means all concepts of the Play Back Ontology are somehow related to at least one media object. The range of these media objects is currently restricted to the concepts bibo:Document and frbr:Endeavour, incl. all their sub classes, e.g. mo:Track.

The graphics above illustrate the pbo:Playlist concept, which is a sub class of bibo:Document and olo:OrderedList. Hence, a specialized ordered list of the media domain. Therefore, a pbo:Playlist instance consists of pbo:PlaylistSlot instances (related by pbo:playlist_slot), which are related to at least one media object by using the property pbo:playlist_item. pbo:Playlist has a further sub class, pbo:FixedPlaylist, to described playlists or sections of playlists, which have a strict order, e.g. a section of music tracks that should be played always one after another, or that are somehow related to each other. Furthermore, pbo:Playlist instances can be related to something by using the property pbo:playlist. To complete the description of the playlist concept of the Play Back Ontology in its current state, it is also necessary to mention the semantic relation pbo:transition, which can be used to associate a description of a transition between two neighbouring playlist slots, e.g. two successice music tracks in a dj mix.

The Play Back Ontology consists further more of a couple of media action counters, which are represented by pbo:MediaActionCounter. In the graphic above you can see this concept and its sub classes pbo:PlayBackCounter and pbo:SkipCounter. Due to the property pbo:media_object, which is a sub property of co:object, it is possible to only associate media objects to pbo:MediaActionCounter instances. The same behaviour is realized for media object relations to co:ScrobbleEvent instances by using the property pbo:media_scrobble_object. Finally, one can represent the skip time of a media object for a skip event by utilizing the refined scrobble event pbo:SkipEvent, which is in the domain of the property pbo:skip_time.
Below are examples of use cases of the Play Back Ontology. The first one describes a music playlist and the second one the usage of play back and skip counter.

@prefix xsd: . @prefix dc: . @prefix olo: . @prefix pbo: . @prefix ao: . @prefix mo: . @prefix ex: . @prefix sim: . ex:FunkyPlaylist a pbo:Playlist ; dc:title "Funky Playlist"^^xsd:string ; dc:description "A playlist full of funky legends"^^xsd:string ; dc:creator ; olo:length 2 ; sim:association ex:ZazisAssociation ; sim:association ex:BobsAssociationInUse ; pbo:playlist_slot [ a pbo:PlaylistSlot ; olo:index 1 ; pbo:playlist_item ex:SexMachine ] ; pbo:playlist_slot [ a pbo:PlaylistSlot ; olo:index 2 ; pbo:playlist_item ex:GoodFoot ] . ex:SexMachine a mo:Track ; dc:title "Sex Machine"^^xsd:string ; dc:creator . ex:GoodFoot a mo:Track ; dc:title "Good Foot"^^xsd:string . ex:ZazisAssociation a sim:Association ; dc:creator ; ao:genre "Funk"^^xsd:string ; ao:mood "party"^^xsd:string ; ao:occasion "my birthday party 2008"^^xsd:string . ex:BobsAssociation a sim:Association ; dc:creator ; ao:genre ex:Funk ; ao:mood "happy"^^xsd:string ; ao:occasion "good feeling music"^^xsd:string . ex:BobsAssociationInUse a ao:LikeableAssociation ; ao:included_association ex:BobsAssociation ; ao:likeminded . ex:Funk a mo:Genre .

The graphic (see here, for another graph view, and here, for an extended graph
view, of this example) above illustrates the RDF/Turtle representation below the graphic, which is a music playlist example created with the Play Back Ontology (see also RDF and N3 for downloadable representations of this example). This music playlist is modeled as pbo:Playlist instance and is annotated with further editoral metadata, e.g. a title, a description and a creator, and has a fixed length (olo:length) that represents the number of slots this specific ordered list instance consist of. Each slot is modeled as pbo:PlaylistSlot instance to ensure that only some media objects are in the playlist. This is especially realized by the range restriction of pbo:playlist_item. In the example these items are mo:Track instances.
Furthermore, a playlist can be annotated with association statements (sim:Association based) related by sim:association. Please have a look at the previous blog post about the Association Ontology for an explanation of these statements.

@prefix xsd: . @prefix dc: . @prefix co: . @prefix pbo: . @prefix mo: . @prefix ex: . @prefix event: . @prefix time: . @prefix am: . @prefix owl: . @prefix ao: . ex:PlayBackCounter a pbo:PlayBackCounter ; dc:title "Play Back Counter"^^xsd:string ; dc:creator ; dc:description "A play back counter of a specific music track"^^xsd:string ; co:count 2 ; pbo:media_object ex:SexMachine . ex:SkipCounter a pbo:SkipCounter ; dc:title "Skip Counter"^^xsd:string ; dc:creator ; dc:description "A skip counter of a specific music track"^^xsd:string ; co:count 1 ; pbo:media_object ex:SexMachine . ex:SexMachine a mo:Track ; dc:title "Sex Machine"^^xsd:string ; dc:creator . ex:SexMachineSE1 a co:ScrobbleEvent ; event:time [ a time:Instant ; time:inXSDDateTime "2010-07-15T11:21:52+01:00"^^xsd:dateTime ] ; event:agent ; ao:used_application ex:iTunes ; ao:used_device ex:MyPC ; co:event_counter ex:PlayBackCounter . ex:SexMachineSE2 a co:ScrobbleEvent ; event:time [ a time:Instant ; time:inXSDDateTime "2010-07-15T11:27:52+01:00"^^xsd:dateTime ] ; event:agent ; ao:used_application ex:iTunes ; ao:used_device ex:MyPC ; co:event_counter ex:PlayBackCounter . ex:SexMachineSE3 a co:ScrobbleEvent ; event:time [ a time:Instant ; time:inXSDDateTime "2010-07-15T11:35:52+01:00"^^xsd:dateTime ] ; event:agent ; ao:used_application ex:iTunes ; ao:used_device ex:MyPC ; co:event_counter ex:SkipCounter . ex:iTunes a am:Application . ex:MyPC a owl:Thing .

The graphic (see here, for an extended graph view) above illustrates the RDF/Turtle representation below the graphic, which describes a play back and skip counter created with the Play Back Ontology (see also RDF and N3 for downloadable representations of this example). It shows, how co:Counter can be specialized as a play back counter (pbo:PlayBackCounter) and as a skip counter (pbo:SkipCounter) for a specific music track (here of the type mo:Track), related by the property pbo:media_object.
Each time, when this specific music track was played, a co:ScrobbleEvent instance was created and linked to its play back counter by the property co:event_counter. This happened also, when this specific music track was skipped. The only difference is that such an event is related to its skip counter pbo:SkipCounter.
To describe scrobble events more in detail (besides event:time and event:agent), one can add properties such as ao:used_application (to describe the application, which is related to the scrobbling activity, e.g. ex:iTunes) or ao:used_device (to describe the device, which is related to the scrobbling activity, e.g. ex:MyPC).

The Play Back Ontology and the illustrated examples above demonstrates the reutilization, specialization and application of concepts of existing ontologies, as mention in the introduction of this blog post. I like to invite you to create further, more specialized concepts and properties, which are based on the introduced ontologies.

I would like to thank very much the whole Music Ontology Specification mailing list group to help to establish this multiple purpose play back ontology and especially Kurt Jacobson for providing everytime new input and ideas. Please feel free to reuse and extend the Play Back Ontology also for your own projects (let me know your use cases ). Comments, suggestions and critics are also very welcome.

Cheers,

Bob