You need it, you want it, you get it ;) - The Recommendation Ontology

[Bob Ferris]

Hello everybody,

today I like to announce a first draft of the Recommendation
Ontology[1,2,3]. As far as I get an overview, there exists currently no
ontology, which address this purpose as I intended it.
With this ontology it should be possible to associate a recommendation
to someone or something. The recommendation itself includes the
recommendation objects and a relation to the recommender, e.g. an
is:InfoService instance. The association and/or similarity statements,
which are describing the reasons for a recommendation, can be described
on the basis of the sim:Association[4] concept, which can be related to
a sim:association concept by the property ao:included_association[5].
The aim of the Recommendation Ontology is to serve recommendations from
different information services to users (or something) by having also
the opportunity to describe the reasons for the recommendation and
hence, enable transparency. A use case example, which follows the idea
of transparency recommendations is dbrec.net[6].

Please let me know, what do you think about this modelling. Comments,
critics and suggestions are very welcome.

Cheers,

Bob

[1] http://smiy.sourceforge.net/rec/rdf/recommendationontology.n3
[2] http://smiy.sourceforge.net/rec/rdf/recommendationontology.owl
[3] http://smiy.sourceforge.net/rec/gfx/rec_-_recommendation.gif
[4] http://purl.org/ontology/similarity/Association
[5]
http://purl.org/ontology/ao/associationontology.html#included_association
[6] http://dbrec.net/

[za...@elbklang.net]

Hello again,

today I modelled a music recommendation[1,2] example with help of the
Recommendation Ontology. Therefore, I also added new extensions to the
ontology for testing purpose, these are:

- rec:RankedRecommendation - a ranked recommendation that includes an
ordered list of recommendations
- rec:ranked_recommendation_object - a ranked recommendation object in a
ranked recommendation

Please let me know, what do you think about this modelling. With the help
of ranked recommendations one is able to create an order re. the
recommendation object without getting into the details about the
creation of this order. Hence, such a ranked recommendation is more or
less on its highest level. However, one can also add some background
information (see the sim:included_association relations), which are the
hook to the details.
Furthermore, this modelling should enable the comparison of different
recommendations/ranked recommendation for someone/something.

I'm currently a bit unsure, where I should include the subject of a
recommendation, if it is a personalised recommendation. I thought that
the user would be related by rec:recommendation (ex:AUser
rec:recommendation ex:ARecommendation). However, the subject, e.g. seed
tracks (objects) etc. must be related by included associations then, or?
Another option would be to relate them directly by sim:subject, but there
is also the use case where a recommendation is based on an
association statement as it is exemplified here[3]. This leads maybe to
some inconsistency ;)

Any suggestions? (Kurt? ;) )

Cheers,

Bob

[1] http://smiy.sourceforge.net/rec/examples/N3/music_rec_-_example.n3 [2]
http://smiy.sourceforge.net/rec/examples/N3/music_rec_-_example.owl [3]
http://purl.org/ontology/ao/associationontology.html#sec-example

[Joshan Mahmud]

Hi everyone

The Recommendation Ontology looks quite interesting...

Kurt - could you explain a bit more as how to use it? I'm hoping to
write something which would make recommendations of pieces of music
based on specific musical attributes (such as harmonic progression,
rhythm etc) - could the recommendation ontology be used for that?

Thanks
Joshan

> --
> You received this message because you are subscribed to the Google
> Groups "Music Ontology Specification Group" group.
> To post to this group, send email to music-ontology-sp...@googlegroups.com
> .
> To unsubscribe from this group, send email to music-ontology-specific...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/music-ontology-specification-group?hl=en
> .
>

[za...@elbklang.net]

Hi Joshan,

I think this should be possible with the Similarity Ontology[1] (please
have a look at the examples and sim:AssociationMethod). The Recommendation
Ontology works also on top of the Similarity Ontology and is currently
only a draft. So be careful, if you are planning to use the Recommendation
Ontology. There might change some things in the future (the whole ontology
is maybe obsolete).
Another possibility is maybe the Association Ontology[2] (another
conceptual idea ;) ), if would like to model something like idiosyncratic
music genre. You can for example create sub properties from
dcterms:suject, e.g. ex:rhythm.

Cheers,

Bob

[1] http://purl.org/ontology/similarity/
[2] http://purl.org/ontology/ao/associationontology.html

[Alex]

Hi,

On Jul 31, 1:08 pm, z...@elbklang.net wrote:
> Hello again,
>
> today I modelled a music recommendation[1,2] example with help of the
> Recommendation Ontology. Therefore, I also added new extensions to the
> ontology for testing purpose, these are:
>
> - rec:RankedRecommendation - a ranked recommendation that includes an
> ordered list of recommendations
> - rec:ranked_recommendation_object - a ranked recommendation object in a
> ranked recommendation
>
> Please let me know, what do you think about this modelling. With the  help
> of ranked recommendations one is able to create an order re. the
> recommendation object without getting into the details about the
> creation of this order.

In dbrec, I've modeled the LDSD ontology (that should be mapped
further with MuSim and now with this Recommendation Ontology, I'll
email the list about this later).
Instead of ranking the recommendations, each recommendation got a
particular score, so that I can use ORDER / OFFSET in SPARQL to order
the recommendations and limit them to a particular set.
I found that more appropriate than a ranked object, but I guess both
can be combined if needed.

Best,

Alex.

> >http://purl.org/ontology/ao/associationontology.html#included_associa...
>
> [6]http://dbrec.net/

[za...@elbklang.net]

Hi Alex,

thanks a lot for you response. That means that you are feeling fine with
the current modelling?

Am 31.07.2010 19:12, schrieb Alex:
> Hi,
>
>
> On Jul 31, 1:08 pm, z...@elbklang.net wrote:
>> Hello again,
>>
>> today I modelled a music recommendation[1,2] example with help of the
>> Recommendation Ontology. Therefore, I also added new extensions to the
>> ontology for testing purpose, these are:
>>
>> - rec:RankedRecommendation - a ranked recommendation that includes an
>> ordered list of recommendations
>> - rec:ranked_recommendation_object - a ranked recommendation object in a
>> ranked recommendation
>>
>> Please let me know, what do you think about this modelling. With the help
>> of ranked recommendations one is able to create an order re. the
>> recommendation object without getting into the details about the
>> creation of this order.
>
> In dbrec, I've modeled the LDSD ontology (that should be mapped
> further with MuSim and now with this Recommendation Ontology, I'll
> email the list about this later).
> Instead of ranking the recommendations, each recommendation got a
> particular score, so that I can use ORDER / OFFSET in SPARQL to order
> the recommendations and limit them to a particular set.
> I found that more appropriate than a ranked object, but I guess both
> can be combined if needed.

Well, I introduced the "high level" ranking for recommendations, which are
probably somewhere calculated, e.g. Last.fm or EchoNest, and then
requested by a customer (probably over a REST web service), which likes to
reuse these recommendations. As you can see from the example[1,2], the
weights, distances or whatever similarity metrics are separately attached
to the recommendation.
Btw, is it also possible to retrieve the similarity descriptions ("Why are
they related?"), which are created at dbrec, as Semantic Graph (RDF/XML,
RDF/Turtle, ...) somewhere.

I would be very happy, if you are doing the mapping to the Similarity and
Recommendation Ontology, because dbrec reflects a very good (my initially
intended) use case.

[Kurt J]

Hi Bob-o,

I think this is an interesting idea. Using OLO is a nice touch.

One criticism that has been leveled at MuSim is that it is impractical
for a large corpus of items. If you have a set of N things you
potentially need (N-1)^2 similarity/associations/recommendations.
With MuSim this could really bloat your triple store. I'm afraid the
Recommendation Ontology approach suffers from the same problem. I
think including associations with ao:included_association as well as
recommendations is a bit redundant, and in a practical appllicaiton
you probably wouldn't do this. However, I agree an association is not
quite the same thing as a recommendation. Anyway without the
associations, a recommendation modeling is slightly more efficient
than a musim modeling i think (4 triples per item in rec and 5 triples
per item in musim if i count right). So well done!

[snip]

> I'm currently a bit unsure, where I should include the subject of a
> recommendation, if it is a personalised recommendation. I thought that
> the user would be related by rec:recommendation (ex:AUser
> rec:recommendation ex:ARecommendation). However, the subject, e.g. seed
> tracks (objects) etc. must be related by included associations then, or?
> Another option would be to relate them directly by sim:subject, but  there
> is also the use case where a recommendation is based on an
> association statement as it is exemplified here[3]. This leads maybe to
> some inconsistency ;)

this is a very important point i think. personalize recommendations
are a big deal and this should be very clear in the modeling imho.
maybe you introduce another property here?

rec:for a rdfs:Class;
rdfs:domain rec:Recommendation ;
rdfs:range sioc:User .

not sure this is really a great solution tho. consider there are a
variety of scenarios: recommendation of an item based on another
item, recommendation of an item based on a user profile,
recommendation of an item based on interest in an item and a user
profile, and even recommendations with no basis! perhaps there's even
other scenarios i'm not considering...

/me having a think about it...

-kurt j

[Kurt J]

Hi Joshan,

You can use MuSim for the use case you describe:

:HarmonicallySimilar a sim:AssociationMethod ;
dc:description "similarity by harmonic progression" .

:RhytmicallySimilar a sim:AssociationMethod;
dc:description "similar rhythms" .

:SignalA a mo:Signal .
:SignalB a mo:Signal .
:SignalC a mo:Signal .

[a sim:Similarity ;
sim:element :SignalA ;
sim:element :SignalB ;
sim:method :HarmonicallySimilar ]

[a sim:Similarity ;
sim:element :SignalB ;
sim:element :SignalC ;
sim:method :RhythmicallySimilar ]

There is an example implementation that might help here:

http://classical.catfishsmooth.net/about

Altho it is in desparate need of cleaning up. In the above example
there are three association methods - audio-based timbre similarity,
audio-based tonality similarity, and expert determined influence
between artists. You can see examples of how these similarities can
be combined with sparql.

http://classical.catfishsmooth.net/snorql/

Hope that helps! Let me know if I can be of any more assistance.

-Kurt J

>> [1] http://smiy.sourceforge.net/rec/examples/N3/music_rec_-_example.n3 [2]

[zazi]

Hi Kurt,

thanks a lot for reply.

On 31 Jul., 23:31, Kurt J <kur...@gmail.com> wrote:
> Hi Bob-o,
>
> I think this is an interesting idea.  Using OLO is a nice touch.
>

However, it's the question, if really need this explicit ordering
here, or, if it is enough to create this ordering indirect by a SPARQL
query. One can also represent the recommendations itself without a
ranking:

rec:recommendation_object <http://dbtune.org/musicbrainz/resource/
track/097c362d-72b7-4a53-96e2-d9ff02f8be1f> ;
rec:ranked_recommendation_object <http://dbtune.org/musicbrainz/
resource/track/161d35d9-3e31-41e9-8392-cf5d2c03b31d> ;
rec:ranked_recommendation_object <http://dbtune.org/musicbrainz/
resource/track/093c1742-ebda-45cd-a50c-734e5d92e7f2> ;
rec:ranked_recommendation_object <http://dbtune.org/musicbrainz/
resource/track/0a208327-525a-429b-8e79-51669bfb81f7> ;
rec:ranked_recommendation_object <http://dbtune.org/musicbrainz/
resource/track/0161855d-0b98-4f2d-b2ab-446dbd8d6759> ;
rec:ranked_recommendation_object <http://dbtune.org/musicbrainz/
resource/track/014f2510-e653-43e9-862a-880ac6388bb1> ;
rec:ranked_recommendation_object <http://dbtune.org/musicbrainz/
resource/track/0ab210b0-18c6-4c52-aee7-78f6012b9192> ;
rec:ranked_recommendation_object <http://dbtune.org/musicbrainz/
resource/track/027326ef-1455-48c9-8543-ac908eb71925> ;
rec:ranked_recommendation_object <http://dbtune.org/musicbrainz/
resource/track/04dc3d0b-dff4-41a0-8bf3-12b4b34460a6> ;
rec:ranked_recommendation_object <http://dbtune.org/musicbrainz/
resource/track/0348eea1-8178-4dc1-8a37-d09b5897ace2> ;

> One criticism that has been leveled at MuSim is that it is impractical
> for a large corpus of items.  If you have a set of N things you
> potentially need (N-1)^2 similarity/associations/recommendations.

Yes, of course I prefer a transparent recommendation. The
recommendation itself would also work without the "attached"
similarity statements. There are the recommendation objects
(rec:recommendation_object), the recommender (rec:recommender), the
recommendation subject (rec:recommendation)

[zazi]

Sorry for the the previous email. The draft was wrongly sent by some
reason :\

Hi Kurt,

thanks a lot for reply.

On 31 Jul., 23:31, Kurt J <kur...@gmail.com> wrote:

> Hi Bob-o,

> I think this is an interesting idea. Using OLO is a nice touch.

However, it's the question, if really need this explicit ordering
here, or, if it is enough to create this ordering indirect by a SPARQL
query. One can also represent the recommendations itself without a
ranking:

ex:AMusicRecommendation a rec:Recommendation ;
rec:recommender isi:lastfm ;

rec:recommendation_object <http://dbtune.org/musicbrainz/resource/
track/097c362d-72b7-4a53-96e2-d9ff02f8be1f> ;

rec:rrecommendation_object <http://dbtune.org/musicbrainz/
resource/track/161d35d9-3e31-41e9-8392-cf5d2c03b31d> ;
rec:recommendation_object <http://dbtune.org/musicbrainz/
resource/track/093c1742-ebda-45cd-a50c-734e5d92e7f2> ;
rec:rrecommendation_object <http://dbtune.org/musicbrainz/
resource/track/0a208327-525a-429b-8e79-51669bfb81f7> ;
rec:recommendation_object <http://dbtune.org/musicbrainz/
resource/track/0161855d-0b98-4f2d-b2ab-446dbd8d6759> ;
rec:recommendation_object <http://dbtune.org/musicbrainz/
resource/track/014f2510-e653-43e9-862a-880ac6388bb1> ;
rec:rrecommendation_object <http://dbtune.org/musicbrainz/
resource/track/0ab210b0-18c6-4c52-aee7-78f6012b9192> ;
rec:recommendation_object <http://dbtune.org/musicbrainz/
resource/track/027326ef-1455-48c9-8543-ac908eb71925> ;
rec:recommendation_object <http://dbtune.org/musicbrainz/
resource/track/04dc3d0b-dff4-41a0-8bf3-12b4b34460a6> ;
rec:recommendation_object <http://dbtune.org/musicbrainz/
resource/track/0348eea1-8178-4dc1-8a37-d09b5897ace2> ;
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 .

> One criticism that has been leveled at MuSim is that it is impractical
> for a large corpus of items. If you have a set of N things you
> potentially need (N-1)^2 similarity/associations/recommendations.

Yes, of course I prefer a transparent recommendation. The
recommendation itself would also work without the "attached"
similarity statements. There are the recommendation objects
(rec:recommendation_object), the recommender (rec:recommender), the

recommendation subject (rec:recommendation, e.g. a foaf:Person
instance) and probably other recommendation subjects (sim:subject,
e.g. mo:Track instances as seed tracks).

> With MuSim this could really bloat your triple store.  I'm afraid the
> Recommendation Ontology approach suffers from the same problem.  I
> think including associations with ao:included_association as well as
> recommendations is a bit redundant, and in a practical appllicaiton
> you probably wouldn't do this.

I think it depends on how a specific recommendation service likes to
deliver the recommendation that means recommendations with similarity
descriptions (transparency) or simply recommendations.

 
> However, I agree an association is not
> quite the same thing as a recommendation.  Anyway without the
> associations, a recommendation modeling is slightly more efficient
> than a musim modeling i think (4 triples per item in rec and 5 triples
> per item in musim if i count right).  So well done!

Okay, however, I'm currently not really finally satisfied with the
modelling ;)

>
> [snip]
>
> > I'm currently a bit unsure, where I should include the subject of a
> > recommendation, if it is a personalised recommendation. I thought that
> > the user would be related by rec:recommendation (ex:AUser
> > rec:recommendation ex:ARecommendation). However, the subject, e.g. seed
> > tracks (objects) etc. must be related by included associations then, or?
> > Another option would be to relate them directly by sim:subject, but  there
> > is also the use case where a recommendation is based on an
> > association statement as it is exemplified here[3]. This leads maybe to
> > some inconsistency ;)
>
> this is a very important point i think.  personalize recommendations
> are a big deal and this should be very clear in the modeling imho.
> maybe you introduce another property here?
>
> rec:for a rdfs:Class;
>    rdfs:domain rec:Recommendation ;
>    rdfs:range sioc:User .

Nice, this would probably be the inverse property of
rec:recommendation, (more or less) where I'm thinking about all the
time. However, this property could also somehow related to
sim:subject. Maybe one have the describe this concern in separate
triples (rec:recommendation_object could also a sub property of
sim:object; or rec:recommendation_object is for this reason probably
also obsolete), e.g.

example 1:

ex:ARecommendation a rec:Recommendation ;
rec:for ex:AMusicTrack ; # the relation the
recommendation is created for
sim:subject ex:AMusicTrack ; # the relation the recommendation is
based on
.
ex:AMusicTrack a mo:Track .

and another example (example 2):

ex:ARecommendation a rec:Recommendation ;
rec:for ex:APerson ; # the relation the recommendation is
created for
sim:subject ex:AMusicTrack ; # the relation the recommendation is
based on
.
ex:APerson a foaf:Person .
ex:AMusicTrack a mo:Track .

>
> not sure this is really a great solution tho.

That's also currently my opinion, too. ;)

> consider there are a
> variety of scenarios:  

- recommendation of an item based on another item
-> see example 1, where such a recommendation can also have
several subjects (I'm unsure, whether this was initially intend by or
subject/object design).

- recommendation of an item based on a user profile
-> see example 2, where a user profile can also be a subject, too

- recommendation of an item based on interest in an item and a user
profile
-> see example 2 (the interest is part of the user profile)

- profile, and even recommendations with no basis!  
-> well I think, a recommendation is every time based on
something, because there must be a reason for this recommendation

- perhaps there's even other scenarios i'm not considering...
-> I can't currently remember more scenarios ;)

Finally, to sum up a bit what's important for me and should be
clarified:

1. The alignment of rec:recommendation_object to sim:object
2. rec:for owl:inverseOf rec:recommendation?
3. rec:for and sim:subject alignment
4. What about an inverse property of sim:association?
5. Do we really need rec:RankedRecommendation?

I think that should be all for the moment ;)

Cheers,

Bob

[zazi]

Hi Kurt,
Hi Joshan,
Hi all,

On 31 Jul., 23:43, Kurt J <kur...@gmail.com> wrote:
> Hi Joshan,
>
> You can use MuSim for the use case you describe:
>
> :HarmonicallySimilar a sim:AssociationMethod ;
>   dc:description "similarity by harmonic progression" .
>
> :RhytmicallySimilar a sim:AssociationMethod;
>   dc:description "similar rhythms" .
>
> :SignalA a mo:Signal .
> :SignalB a mo:Signal .
> :SignalC a mo:Signal .
>
> [a sim:Similarity ;
>  sim:element :SignalA ;
>  sim:element :SignalB ;
>  sim:method :HarmonicallySimilar ]
>
> [a sim:Similarity ;
>  sim:element :SignalB ;
>  sim:element :SignalC ;
>  sim:method :RhythmicallySimilar ]
>

How can I efficiently combine different similarity methods, e.g.

ex:ASimilarity a sim:Similarity ;

sim:element :SignalA ;
sim:element :SignalB ;

sim:method :HarmonicallySimilar ;
sim:method :RhythmicallySimilar .

or

ex:APlaylist a pbo:Playlist ;
sim:association ex:AnotherSimilarity .
pbo:playlist_item [
a pbo:PlaylistSlot ;
pbo:playlist_item :Signal A;
olo:index 1
] ;
pbo:playlist_item [
a pbo:PlaylistSlot ;
pbo:playlist_item :Signal B;
olo:index 2
] ;
olo:lengh 2 .

ex:AnotherSimilarity a sim:Similarity ;
sim:method :HarmonicallySimilar ;
sim:method :RhythmicallySimilar .

In the examples at your SNORQL endpoint, you've created for a combine
similarity method a new one.

Cheers,

Bob

[Joshan Mahmud]

Cheers Bob!

I better get working!

Josh

[zazi]

Hi Joshan,

On 1 Aug., 15:53, Joshan Mahmud <joshan.mah...@gmail.com> wrote:
> Cheers Bob!
>
> I better get working!

"How can I efficiently combine different similarity methods" should be
a question. I'm not sure, whether this is really possible ;) (let's
wait of an answer from Kurt).

Cheers,


Bob

[Kurt J]

Hello,

>ex:ASimilarity a sim:Similarity ;
> sim:element :SignalA ;
> sim:element :SignalB ;
> sim:method :HarmonicallySimilar ;
> sim:method :RhythmicallySimila

well i'd make this two statements

ex:ASimilarity a sim:Similarity ;
sim:element :SignalA ;
sim:element :SignalB ;

sim:method :HarmonicallySimilar .

ex:AnotherSimilarity a sim:Similarity ;

sim:element :SignalA;
sim:element :SiganlB;
sim:method :RhytmicallySimilar ;

and then you combine in SPARQL

SELECT ?sigA ?sigB WHERE {

?sim1 sim:element ?sigA, ?sigB ;
sim:method :RhythmicallySimilar .

?sim2 sim:element ?sigA, ?sigB ;
sim:method :HarmonicallySimilar .

}

In this query you're finding ?sigA and ?sigB that share _both_ a
harmonic and rhythmic similarity according to those two specific
association methods. Make sense?

At classical.catfishsmooth.net/snorql this is what we're doing as well
actually. Association methods are not merged in the RDF but in the
SPARQL queries over the RDF.

I really need to setup a good example with _lots_ of audio-based
analysis stuff. Sorry the crap at classical.catfishsmooth is the best
i've got right now. And i've got other things on the plate right now
(stay tuned for details ;-)

-Kurt J

[Kurt J]

Hi again,

>>ex:ASimilarity a sim:Similarity ;
>> sim:element :SignalA ;
>> sim:element :SignalB ;
>> sim:method :HarmonicallySimilar ;
>> sim:method :RhythmicallySimila
>
> well i'd make this two statements
>
> ex:ASimilarity a sim:Similarity ;
>  sim:element :SignalA ;
>  sim:element :SignalB ;
>  sim:method :HarmonicallySimilar .
>
> ex:AnotherSimilarity a sim:Similarity ;
>  sim:element :SignalA;
>  sim:element :SiganlB;
>  sim:method :RhytmicallySimilar ;

let me be more clear about why this is (i believe) the right way to
model a multi-faceted similarity. in our example here, we are talking
about two distinct dimensions of similarity - rhythmic and harmonic.
MuSim is designed to embrace compound similarities - two things can be
similar in many different ways. In some applications we might care
only about rhythmic similarities, sometimes we might care about
harmonic, and sometimes we might care about both.

There's nothing inherently wrong with creating a merged association
method that deals with both rhythm and harmony if that's what your
application calls for. But i would call this a new association
method, e.g.

:RhythmicHarmonicSimilarityMethod a sim:Similarity .

ex:ASimilarity a sim:Similarity ;
sim:element :SignalA ;
sim:element :SignalB ;

sim:method :RhythmicHarmonicSimilarityMethod .

I think it makes sense for the cardinality of sim:method to be exactly
one. An association should be derived from a single association
method. I might add this restriction to MuSim unless there are any
serious objections (Bob-o?)

-kurt j

[zazi]

Hi Kurt,

On 1 Aug., 17:48, Kurt J <kur...@gmail.com> wrote:
> Hi again,
>
>
>
> >>ex:ASimilarity a sim:Similarity ;
> >> sim:element :SignalA ;
> >> sim:element :SignalB ;
> >> sim:method :HarmonicallySimilar ;
> >> sim:method :RhythmicallySimila
>
> > well i'd make this two statements
>
> > ex:ASimilarity a sim:Similarity ;
> >  sim:element :SignalA ;
> >  sim:element :SignalB ;
> >  sim:method :HarmonicallySimilar .
>
> > ex:AnotherSimilarity a sim:Similarity ;
> >  sim:element :SignalA;
> >  sim:element :SiganlB;
> >  sim:method :RhytmicallySimilar ;
>
> let me be more clear about why this is (i believe) the right way to
> model a multi-faceted similarity.  in our example here, we are talking
> about two distinct dimensions of similarity - rhythmic and harmonic.
> MuSim is designed to embrace compound similarities - two things can be
> similar in many different ways.  In some applications we might care
> only about rhythmic similarities, sometimes we might care about
> harmonic, and sometimes we might care about both.

Yes, I'm fully aware of multi-facet similarities. It's just the way
how to model and (re-)utilize them.

>
> There's nothing inherently wrong with creating a merged association
> method that deals with both rhythm and harmony if that's what your
> application calls for.  But i would call this a new association
> method, e.g.
>
> :RhythmicHarmonicSimilarityMethod a sim:Similarity .
>
> ex:ASimilarity a sim:Similarity ;
>  sim:element :SignalA ;
>  sim:element :SignalB ;
>  sim:method :RhythmicHarmonicSimilarityMethod .
>
> I think it makes sense for the cardinality of sim:method to be exactly
> one.  An association should be derived from a single association
> method.  I might add this restriction to MuSim unless there are any
> serious objections (Bob-o?)

I have no problem with defining this also in a new method. However,
then it should probably be possible, to associate also the methods for
the different facets to this merged similarity method. I guess,
sim:workflow is the probably a good property here (or
ao:included_association).
I know that I can merge results with the help of a SPARQL queries. I
know also that I can construct new graphs on to of these results.
However, I think there should be a way, where it is possible to
efficiently reutilize them directly in RDF graphs and also with help
of SPARQL queries. I have not really that experience to say, when it
might be better to use this technique, instead of the other technique.
So please feel free as you like to do it, Kurt ;)


Ontology modelling is still more art than a science ;)

Cheers,


Bob

PS: I'll later come up with some examples modeled with help of an
ontology, which addresses also the annotation/association domain
(what's there difference between them?)

[zazi]

Hello again,

as earlier announced, I'd like to present association/modelling
examples with another annotation ontology. Last night, I had the time
to have a deeper look into the OAC Vocabulary from the Open Annotation
Collaboration[1] and I thought that this ontology also reflects my
aims re. annotation/association modelling. Unfortunately, the site
(the server[2]), where they described this vocabulary, was down today.
However, they wrote that their ontology is based on the Annotea
Annotation Schema with has its roots back in the year 2000. Hence, I
thought, it might be good to try this one. This schema includes a
general annotation concept for reification of the "annotates"
property, which can also be founded in several other annotation
ontologies and which is also realized by the Similarity Ontology.
Since the Annotea Annotation Schema was created in the early days of
RDF, I thought it might be good to shift this ontology and its related
Annotea Annotation Types namespace to the OWL world[5,6,7,8] (also for
testing and extension purpose).
However, when I came up to the example modelling (I took the annotated
music playlist example[9]), I noticed that there are still many
semantic relations not available. I observed that it is often the
problem in the different annotation ontologies that the developers
like to model a general applicable annotation model and thereby they
are to focused on their domain and probably lost the overview that the
annotation concept would be reutilized as extension or component in
other applications (to annotate concepts of other ontologies).
For example the Annotea Association Schema has a property called
anno:related, which should be used to related a comment, question or
whatever (the content of the annotation) to the anno:Annotation
instance (therefore I added anno:Annotation also as domain of this
property). This property was declared as to be subpropertied. That
means, every semantically richer property should a sub property of
this property and hence, also with the domain of anno:Annotation.
However, if I have a property, which is initially intended to be
directly related to something, e.g. mo:genre, and I simply want to
reuse it also in the annotation context, I can't really do this
without the application of Named Graphs, or? That was the reason, why
I kept the domain of my dcterms:subject sub properties open in the
Association Ontology.
Another example is from the OAC Vocabulary. They renamed the
properties from the Annotea Annotation Schema a bit there
(anno:hasAnnotation to oac:hasTarget and anno:body to oac:hasBody).
Furthermore, they added ranges to these annotation relation properties
(oac:Target and oac:Body). That means every thing that is used to
establish a oac:Annotation must be a oac.Target or oac:Body. Okay, I
can add this to the type description of my instances. However, this
would blew up the whole graph a bit, or? I want to reutilize existing
concepts directly for annotation statements.
Finally, I end up with copying more or less my whole association
ontology to the Annotea namespace for testing purpose and modeled then
my example[10], which now not really differs from the other example. I
more or less also end up with the conclusion that a Named Graph
(Nested Graph or whatever) based annotation/association statement
modelling approach might be the best one, because I hopefully can
reutilize, existing, semantically rich properties, without extending
their domain (to an annotation concept) and I don't have to attach
extra types to my instances to make them in an annotation/association
statement usable. In the NEPOMUK Annotation Ontology[11], they
demonstrated more or less how one can do this. However, they also used
some concepts, which are restricted to their application domain, and
they don't really aligned their ontology to DC, Review Ontology, Tag
Ontology etc.
I'm now really confused, which way I should go for solving the
annotation/association "problem".

Cheers,


Bob

[1] http://www.openannotation.org/
[2] http://annotation.lanl.gov/
[3] http://www.w3.org/2000/10/annotation-ns#
[4] http://www.w3.org/2001/Annotea/
[5] http://smiy.svn.sourceforge.net/viewvc/smiy/annotea/trunk/rdf/annotea.n3
[6] http://smiy.svn.sourceforge.net/viewvc/smiy/annotea/trunk/rdf/annotea.owl
[7] http://smiy.svn.sourceforge.net/viewvc/smiy/annotea/trunk/rdf/annoteaannotationtypes.n3
[8] http://smiy.svn.sourceforge.net/viewvc/smiy/annotea/trunk/rdf/annoteaannotationtypes.owl
[9] http://smiy.sourceforge.net/pbo/examples/N3/playlist_-_example.n3
[10] http://smiy.svn.sourceforge.net/viewvc/smiy/annotea/trunk/examples/N3/anno_-_annotation_-_example.n3
[11] http://www.semanticdesktop.org/ontologies/nao/

[Danny Ayers]

Hi Bob,

The Recommendation Ontology sounds a very good idea - looks like it
should be useful around social web sites and expressing things like
Amazon's recommendations.

Another example you may like to try is using it alongside the Review Vocabulary:

http://vocab.org/review/terms.html

To see the key terms in use, pick any review from:

http://revyu.com/

and have a look through the RDF Metadata link on the right.

Don't know if you seen it already, but SpecGen is very handy for
generating HTML docs from RDF/XML (to create the "namespace
document"):

http://forge.morfeo-project.org/wiki_en/index.php/SpecGen

Cheers,
Danny.

--
http://danny.ayers.name

[zazi]

Hi Danny,

thanks a lot of your response.

On 2 Aug., 08:30, Danny Ayers <danny.ay...@gmail.com> wrote:
> Hi Bob,
>
> The Recommendation Ontology sounds a very good idea - looks like it
> should be useful around social web sites and expressing things like
> Amazon's recommendations.

I've also planned to create an example of amazon recommendations.
However, I'm not familiar with their API and I've founded no
appropriated example of a response of a "suggested item" request (I
think that is the method, where I'll get recommendations from). Maybe
one can provide one for me and I'll transform it into RDF.
In general the recommendation ontology should be applicable, whereever
one needs recommendations (personalized or not)

>
> Another example you may like to try is using it alongside the Review Vocabulary:
>
> http://vocab.org/review/terms.html

I'm aware of the Review Vocabulary. The super class of
rec:Recommendation is ao:LikeableAssociation (from the Association
Ontology[1]), which is a sub class of rev:Review and sim:Association
(from the Similarity Ontology[2]). Hence, I hope one can perfectly
apply review tasks directly on the rec:Recommendation instances. I
thought that it might be useful to enable a direct reutilization of
the review concept, am I right with that? One the other side, they can
maybe perfectly co-exist side by side. The reason for including
rev:Review in that way was that I have also built a property called
ao:likeminded to enable people to like a specific association,
especially in relation to something (please have a look at the example
in the Association Ontology for this use case). "like" is more or less
the simplest form of a review. So I thought that it might probably be
useful to directly align rev:Review here. Please let me me know,
whether you like that alignment.

>
> To see the key terms in use, pick any review from:
>
> http://revyu.com/
>

I'm also aware of this site and its application of the Review
Vocabulary. However, I don't really see the recommendation part in
there. I'm able to tag and review something. Where do I get the
recommendations for something? Can you probably provide an appropriate
example for me, please?

> and have a look through the RDF Metadata link on the right.
>
> Don't know if you seen it already, but SpecGen is very handy for
> generating HTML docs from RDF/XML (to create the "namespace
> document"):
>
> http://forge.morfeo-project.org/wiki_en/index.php/SpecGen

I'm also aware of SpecGen. I have built my own extension[1] on top
Danbri's SpecGen version 5, which can deliver a whole ontology into
XHTML+RDFa. I haven't deployed the specification document for
Recommendation Ontology yet, because I was a bit unsure, whether we
really need this one (it was only a draft of an idea ;) ), or if it is
possible to model this with already existing concepts and properties.
After the feedback from the weekend, I have the feeling that there is
a certain demand for this ontology. Hence, I've planned to deploy a
XHTML-RDFa specification document today for that ontology.

Cheers,


Bob

[1] http://purl.org/ontology/ao/associationontology.html
[2] http://purl.org/ontology/similarity/
[3] http://smiy.svn.sourceforge.net/viewvc/smiy/specgen/trunk/

[zazi]

Hello again,

as promised earlier this day, here is the Recommendation Ontology
Specification document:

http://smiy.sourceforge.net/rec/spec/recommendationontology.html

Be careful re. the links, because they are often set to the PURL URI,
which isn't approved yet (the domain of the PURL URI).

Cheers,


Bob

PS: a simpler example will also follow

[Bob Ferris]

Hello everybody,

FYI, the Recommendation Ontology now officially announced at SMI ;)

The Recommendation Ontology now officially announced ;)
http://smiy.wordpress.com/2010/08/07/the-recommendation-ontology/

Cheers,

Bob

[Kingsley Idehen]

Bob,

Have you considered temporal dimensions re. playlists and favorite music?

--

Regards,

Kingsley Idehen
President & CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

[Bob Ferris]

Hi Kingsley,

Am 07.08.2010 14:05, schrieb Kingsley Idehen:
> Bob Ferris wrote:
>> Hello everybody,
>>
>> FYI, the Recommendation Ontology now officially announced at SMI ;)
>>
>> The Recommendation Ontology now officially announced ;)
>> http://smiy.wordpress.com/2010/08/07/the-recommendation-ontology/
>>
>> Cheers,
>>
>>
>> Bob
>>
> Bob,
>
> Have you considered temporal dimensions re. playlists and favorite music?

What do you mean exactly? Something like a creation and or modification
date? Or something like in the direction of Memento?
I think the whole provenance handling can't be a part of these
ontologies that must be handled by other techniques and systems.
However, in general it should be possible to analyse one's musical taste
of the time re. changes, which can influence then the recommendation
and/or playlist creation tasks. Of course, a continuing analysis of the
musical taste is necessary.

Maybe you can go a bit more into detail, what you are meaning with
considering temporal dimensions.

Cheers,

Bob

[Kingsley Idehen]

Bob Ferris wrote:
> Hi Kingsley,
>
> Am 07.08.2010 14:05, schrieb Kingsley Idehen:
>> Bob Ferris wrote:
>>> Hello everybody,
>>>
>>> FYI, the Recommendation Ontology now officially announced at SMI ;)
>>>
>>> The Recommendation Ontology now officially announced ;)
>>> http://smiy.wordpress.com/2010/08/07/the-recommendation-ontology/
>>>
>>> Cheers,
>>>
>>>
>>> Bob
>>>
>> Bob,
>>
>> Have you considered temporal dimensions re. playlists and favorite
>> music?
>
> What do you mean exactly? Something like a creation and or
> modification date?

Creation and modification dates.

> Or something like in the direction of Memento?
> I think the whole provenance handling can't be a part of these
> ontologies that must be handled by other techniques and systems.
> However, in general it should be possible to analyse one's musical
> taste of the time re. changes, which can influence then the
> recommendation and/or playlist creation tasks. Of course, a continuing
> analysis of the musical taste is necessary.
>
> Maybe you can go a bit more into detail, what you are meaning with
> considering temporal dimensions.

Just want to track the evolution of ones music preferences via a Linked
Data graph :-)

Kingsley
>
> Cheers,
>
>
> Bob

[Bob Ferris]

Am 09.08.2010 00:05, schrieb Kingsley Idehen:
> Bob Ferris wrote:
>> Hi Kingsley,
>>
>> Am 07.08.2010 14:05, schrieb Kingsley Idehen:
>>> Bob Ferris wrote:
>>>> Hello everybody,
>>>>
>>>> FYI, the Recommendation Ontology now officially announced at SMI ;)
>>>>
>>>> The Recommendation Ontology now officially announced ;)
>>>> http://smiy.wordpress.com/2010/08/07/the-recommendation-ontology/
>>>>
>>>> Cheers,
>>>>
>>>>
>>>> Bob
>>>>
>>> Bob,
>>>
>>> Have you considered temporal dimensions re. playlists and favorite
>>> music?
>>
>> What do you mean exactly? Something like a creation and or
>> modification date?
>
> Creation and modification dates.

As it is common I would also use DCTerms for that issue, e.g.

- dcterms:created
- dcterms:modified

>> Or something like in the direction of Memento?
>> I think the whole provenance handling can't be a part of these
>> ontologies that must be handled by other techniques and systems.
>> However, in general it should be possible to analyse one's musical
>> taste of the time re. changes, which can influence then the
>> recommendation and/or playlist creation tasks. Of course, a continuing
>> analysis of the musical taste is necessary.
>>
>> Maybe you can go a bit more into detail, what you are meaning with
>> considering temporal dimensions.
>
> Just want to track the evolution of ones music preferences via a Linked
> Data graph :-)

Yeah, if you mean music preferences than you would like to model user
profiles, the issue I'm currently dealing/struggling with ;)
There was a workshop at VoCamp 2010, where they dealt with this issue
and the alignment of the existing interest modelling ontology (see [1]).
For now, I have pushed the Weighted Interests Vocabulary into another
versions[2,3,4].
On top of the VoCamp proposal and the Weighted Interests Vocabulary
v0.2, I'm currently creating new concepts and properties to model
temporal dynamics of interests, as the modelling from e-foaf[5] is a bit
wrongly interpreted in their example (I guess). I'll like to make use of
the Event Ontology here.
So it's all work progress and the results will follow during the next
few days.

Cheers,

Bob

[1]
http://vocamp.org/wiki/HypiosVoCampParisMay2010#User_.28weighted.29_Interests_Ontology
[2]
http://smiy.svn.sourceforge.net/viewvc/smiy/weightedinterests/trunk/rdf/weightedinterests.n3
[3]
http://smiy.svn.sourceforge.net/viewvc/smiy/weightedinterests/trunk/rdf/weightedinterests.owl
[4]
http://smiy.svn.sourceforge.net/viewvc/smiy/weightedinterests/trunk/rdf/ChangeLog
[5] http://wiki.larkc.eu/e-foaf:interest

[Kingsley Idehen]

Yes, Event Ontology should come in handy for old party playlists, for
instance :-)

Kingsley

>
>
> Bob
>
> [1]
> http://vocamp.org/wiki/HypiosVoCampParisMay2010#User_.28weighted.29_Interests_Ontology
>
> [2]
> http://smiy.svn.sourceforge.net/viewvc/smiy/weightedinterests/trunk/rdf/weightedinterests.n3
>
> [3]
> http://smiy.svn.sourceforge.net/viewvc/smiy/weightedinterests/trunk/rdf/weightedinterests.owl
>
> [4]
> http://smiy.svn.sourceforge.net/viewvc/smiy/weightedinterests/trunk/rdf/ChangeLog
>
> [5] http://wiki.larkc.eu/e-foaf:interest
>

[Bob Ferris]

Hi Kingsley,

If you would like to associate a playlist to an party event, this is
already possible, e.g.

ex:AFunkyPlaylist a pbo:Playlist ;
sim:association ex:KingsleysAssociation .

ex:KingsleysAssociation a sim:Association ;
ao:occasion ex:KingsleysBirthdayParty2008 .

ex:KingsleysBirthdayParty2008 a event:Event .

Cheers,

Bob

> Kingsley
>>
>>
>> Bob
>>
>> [1]
>> http://vocamp.org/wiki/HypiosVoCampParisMay2010#User_.28weighted.29_Interests_Ontology
>>
>> [2]
>> http://smiy.svn.sourceforge.net/viewvc/smiy/weightedinterests/trunk/rdf/weightedinterests.n3
>>
>> [3]
>> http://smiy.svn.sourceforge.net/viewvc/smiy/weightedinterests/trunk/rdf/weightedinterests.owl
>>
>> [4]
>> http://smiy.svn.sourceforge.net/viewvc/smiy/weightedinterests/trunk/rdf/ChangeLog
>>
>> [5] http://wiki.larkc.eu/e-foaf:interest
>>
>
>

--
--------------------BEGIN-OF-SIGNATURE--------------------

Bob Ferris

website: http://elbklang.net
e-mail: za...@elbklang.net

--------------------END-OF-SIGNATURE----------------------