Play Back Ontology

11 views
Skip to first unread message

Bob Ferris

unread,
Jul 19, 2010, 6:12:20 PM7/19/10
to music-ontology-sp...@googlegroups.com
Hello everybody,

I created today the Play Back Ontology[1,2]. This ontology should
include concepts, which are related to the play back domain. That means,
e.g. a play back counter concept, a skip counter concept and a concept
for modelling playlists.
I designed this ontology to be media independent. That means playlists
could be consist of music tracks, videos, slides or even other
playlists. However, I would like to restrict playlists to some kind of
media type. Therefore, I restricted the range of pbo:playlist_item to
bibo:Document[3], frbr:Endeavour and pbo:Playlist currently.
Furthermore, I think a separate playlist concept is useful, because one
could also add properties, e.g. occasion, genre or mood to playlist
(this should maybe also possible multiple times (somehow)).
Finally, I released the very first draft with a lot of open questions.
Here is the TODO list:

* add pbo:Playlist to the domain of mo:genre
* add pbo:Playlist to the domain of mo:mood (which currently not exists)
-> or do we have to shift these concepts upwards (MO independent),
because it is a music independent playlist concept?
(think of movie genres etc.)
* make it possible to associate similarity statements, which are
responsible for the playlist and its order
* create a mechanism for fixed sequences in playlists

=> maybe all these statements must also be associated to a specific user
or a group of users (one could also create a copy
of an equal playlist and associate different association statements (!,
application of sim:Association (?!)) to it.


Re. the association of association/ similarity statements, I think that
we still need an property to associate them to something. That means to
enable reuse of such statement in different contexts, e.g. two playlists.
I like to do something like, e.g. "I used these similarity statements to
created this playlist". Because, such similarity statements can differ
for playlists from specific users, which have maybe exactly the same
order, but the similarities are different.
How can I do that?

That should be enough for today. I really happy about comments,
suggestions and critics.

Cheers,


Bob


[1]
http://smiy.svn.sourceforge.net/viewvc/smiy/playbackonto/trunk/rdf/playbackontology.n3
[2]
http://smiy.svn.sourceforge.net/viewvc/smiy/playbackonto/trunk/rdf/playbackontology.owl
[3]
http://bibotools.googlecode.com/svn/bibo-ontology/trunk/doc/classes/Document___-538479979.html

Bob Ferris

unread,
Jul 21, 2010, 8:17:31 AM7/21/10
to music-ontology-sp...@googlegroups.com
Hello again,

I did some updates yesterday re. the Play Back Ontology[1,2,3]. The
changes are more or less the following ones:

- ADDED: pbo:FixedPlaylist - to express static relations, e.g. "those
three music tracks must always be played in a row"
- outsourced the association statement stuff into a new ontology called
Association Ontology[4,5,6] ;)

This new ontology includes a property (ao:association) to associate
association statements (sim:Association) to something. These
associations could be created by someone that they reflects his/her
opinion to something. Furthermore, if other people have the same opinion
(association) about something, they can add themselves to this
association statement with the property ao:likeminded (I know there is
also a "Like Ontology" from Toby Inkster).
The whole idea behind this modelling is to enable different association
statements to something, which could also be "supported" by further
people. Hence, one could create different associations
(meanings/opinions, ...) based on likeminded groups.
To describe concrete concepts in association statements, I created some
sub properties of dcterms:subject[7], because I think this property fits
best as super property of specific domain properties. Although, there is
also dcterms:type[8]. However, I think this property is intended for
another usage (see [9]).
For the beginning, I created ao:genre, ao:mood and ao:occasion, to
enable the description of these specific domains. With these general
properties it is now possible to use, e.g. ao:genre as super property of
mo:genre.
Finally, I created an example[10,11], where I included all these things
that I've described above. It is a music playlist example that includes
different association statements.

Please let me know what do you think about this modelling and don't
hesitate to ask further questions about the aim of this modelling. I'm
especially interest in your opinion about ao:association as link to
sim:Association.

Cheers,


Bob

[1] http://purl.org/ontology/pbo/core#
[2] http://purl.org/ontology/pbo/playbackontology.n3
[3] http://purl.org/ontology/pbo/playbackontology.owl
[4] http://purl.org/ontology/ao/core#
[5] http://purl.org/ontology/ao/associationontology.n3
[6] http://purl.org/ontology/ao/associationontology.n3
[7] http://dublincore.org/documents/dcmi-terms/#terms-subject
[8] http://dublincore.org/documents/dcmi-terms/#terms-type
[9] http://dublincore.org/documents/dcmi-type-vocabulary/index.shtml
[10] http://smiy.sourceforge.net/pbo/examples/N3/playlist_-_example.n3
[11] http://smiy.sourceforge.net/pbo/examples/RDF/playlist_-_example.rdf

Kurt J

unread,
Jul 21, 2010, 10:43:22 AM7/21/10
to music-ontology-sp...@googlegroups.com
Should we perhaps add ao:association to the sim namespace instead?
The other elements of the ao ontology seem to be rather specific to
your application (perhaps i'm wrong), but in the sim ontology, we
should have a general method to bind a sim:Association to some
arbitrary thing, and this is what ao:association is doing...

sorry, we discussed this offline and i failed to act :-(

> --
> 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.
>
>

Bob Ferris

unread,
Jul 21, 2010, 11:07:36 AM7/21/10
to music-ontology-sp...@googlegroups.com
Hi Kurt,

Am 21.07.2010 16:43, schrieb Kurt J:
> Should we perhaps add ao:association to the sim namespace instead?

+1

Although, I'm unsure, whether the modelling here is good or maybe failed
the whole intend (providing reuseable association statements).

I don't whether we can also adapt sim:subject for this relation.
However, as far as I've understood the intend of this property, it
should be used in combination with sim:object, or?

> The other elements of the ao ontology seem to be rather specific to
> your application (perhaps i'm wrong),

I think these properties could also be applied for similar use cases in
other domains, e.g. for video categorisation/ description. Genre, mood
and occasion are really general concepts. I thought it might be useful
to provide general relations, where more specific sub properties could
be created from, e.g. as mo:genre is an association to musical genre, or
someone else could create a Video Ontology (I know there is at least one
out there) and add a property vo:genre to provide a hook for movie genres.

I'm a bit unsure how to implement the "likeminded" relation (without the
help of named graphs). That means if someone likes to express that this
association statement fits to that thing. Such a "likeminded" relation
is for the connection (ao:association) of association statement and
something. Currently, one expresses that he/she is likeminded to an
association statement itself. However, if this association statement
would be reused several times in different contexts, the likeminded
relation maybe loose then its meaning, or?

Cheers,


Bob

Kurt J

unread,
Jul 21, 2010, 12:33:33 PM7/21/10
to music-ontology-sp...@googlegroups.com
Hi Bob,

>> Should we perhaps add ao:association to the sim namespace instead?
>
> +1
>
> Although, I'm unsure, whether the modelling here is good or maybe failed the
> whole intend (providing reuseable association statements).

i think this modelling is best. it's very open-ended which fits the
spirit of MuSim. sim:association basically binds a sim:Association
with some arbitrary thing (e.g. a transition in a playlist)

please see the updated spec and ontology.

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

> I don't whether we can also adapt sim:subject for this relation. However, as
> far as I've understood the intend of this property, it should be used in
> combination with sim:object, or?

yes these are more specific and relate to a directed sim:Association

>> The other elements of the ao ontology seem to be rather specific to
>> your application (perhaps i'm wrong),
>
> I think these properties could also be applied for similar use cases in
> other domains, e.g. for video categorisation/ description. Genre, mood and
> occasion are really general concepts. I thought it might be useful to
> provide general relations, where more specific sub properties could be
> created from, e.g. as mo:genre is an association to musical genre, or
> someone else could create a Video Ontology (I know there is at least one out
> there) and add a property vo:genre to provide a hook for movie genres.
>
> I'm a bit unsure how to implement the "likeminded" relation (without the
> help of named graphs). That means if someone likes to express that this
> association statement fits to that thing. Such a "likeminded" relation is
> for the connection (ao:association) of association statement and something.
> Currently, one expresses that he/she is likeminded to an association
> statement itself. However, if this association statement would be reused
> several times in different contexts, the likeminded relation maybe loose
> then its meaning, or?

i can see the utility of all this, but not sure how to handle it. my
point was more, that the other concepts in ao are too specific or
tangential to be in the sim namespace.

-kurt

Bob Ferris

unread,
Jul 21, 2010, 1:10:35 PM7/21/10
to music-ontology-sp...@googlegroups.com
Hi Kurt,

Am 21.07.2010 18:33, schrieb Kurt J:
> Hi Bob,
>
>>> Should we perhaps add ao:association to the sim namespace instead?
>>
>> +1
>>
>> Although, I'm unsure, whether the modelling here is good or maybe failed the
>> whole intend (providing reuseable association statements).
>
> i think this modelling is best. it's very open-ended which fits the
> spirit of MuSim. sim:association basically binds a sim:Association
> with some arbitrary thing (e.g. a transition in a playlist)
>
> please see the updated spec and ontology.
>
> http://purl.org/ontology/similarity/
>

I like it! ;)
Thanks for adding this property

>> I don't whether we can also adapt sim:subject for this relation. However, as
>> far as I've understood the intend of this property, it should be used in
>> combination with sim:object, or?
>
> yes these are more specific and relate to a directed sim:Association
>

What about the follow example (taken from my playlist example and extended):

ex:ZazisAssociation a sim:Association ;
dc:creator <http://foaf.me/zazi#me> ;
sim:subject ex:Playlist ;
ao:genre "Funk" ;
ao:mood "party" ;
ao:occasion "my birthday party 2008" .

From my point of view, this expresses the same as:

ex:ZazisAssociation a sim:Association ;
dc:creator <http://foaf.me/zazi#me> ;
ao:genre "Funk" ;
ao:mood "party" ;
ao:occasion "my birthday party 2008" .

ex:Playlist a pbo:Playlist ;
sim:association ex:ZazisAssociation .

In both examples ex:Playlist is the subject of its association statement
ex:ZazisAssociation, or? Furthermore, ao:genre, ao:mood and a:occasion
could be also seen as sub properties of sim:object (maybe) ;)


>>> The other elements of the ao ontology seem to be rather specific to
>>> your application (perhaps i'm wrong),
>>
>> I think these properties could also be applied for similar use cases in
>> other domains, e.g. for video categorisation/ description. Genre, mood and
>> occasion are really general concepts. I thought it might be useful to
>> provide general relations, where more specific sub properties could be
>> created from, e.g. as mo:genre is an association to musical genre, or
>> someone else could create a Video Ontology (I know there is at least one out
>> there) and add a property vo:genre to provide a hook for movie genres.
>>
>> I'm a bit unsure how to implement the "likeminded" relation (without the
>> help of named graphs). That means if someone likes to express that this
>> association statement fits to that thing. Such a "likeminded" relation is
>> for the connection (ao:association) of association statement and something.
>> Currently, one expresses that he/she is likeminded to an association
>> statement itself. However, if this association statement would be reused
>> several times in different contexts, the likeminded relation maybe loose
>> then its meaning, or?
>
> i can see the utility of all this, but not sure how to handle it. my
> point was more, that the other concepts in ao are too specific or
> tangential to be in the sim namespace.

Yes, these properties are independent of the sim namespace. Although
they are somehow related to it ;)b (in my mind)


Re. the the modelling I and also Toby Inkster[1] came up with the idea
of defining "abstract" association statements, which would be reused
from concrete association statements that are related to that
association statement, e.g.

ex:ZazisAssociation a sim:Association ;
dc:creator <http://foaf.me/zazi#me> ;
ao:genre "Funk" ;
ao:mood "party" .

ex:ZazisAssociationInUse a sim:Association ;
includes_association ex:ZazisAssociation ;
ao:likeminded <http://moustaki.org/foaf.rdf#moustaki> .

ex:Playlist a pbo:Playlist ;
sim:association ex:ZazisAssociationInUse .

Maybe, one could also subclass sim:Association as
sim:LikableAssociation, which is the also the domain of ao:likeminded.

What do you think about that proposal.
Furthermore, do you think, whether it makes sense to enable voting also
for single statements in an association statement? For example, if
someone likes the mood description of an association statement, he/she
should be able to vote for that part of an assocation statement. That
means, every statement must be wrapped by a sim:LikeableAssociation :\

Cheers,


Bob


[1] http://esw.pastebin.com/044kXSaY

Bob Ferris

unread,
Jul 21, 2010, 1:18:25 PM7/21/10
to music-ontology-sp...@googlegroups.com
Hi,

I've forgotten to include the links of the graphics, I've created for
the Play Back Ontology (for the visual guys like me :)= ). Here they are:

- the playlist concept:
http://smiy.sourceforge.net/pbo/gfx/pbo_-_playlist_concept.gif

- the play back and skip counter concept:
http://smiy.sourceforge.net/pbo/gfx/pbo_-_play_back_and_skip_counter_concepts.gif

Cheers,


Bob

Bob Ferris

unread,
Jul 21, 2010, 4:11:45 PM7/21/10
to music-ontology-sp...@googlegroups.com
Hi,

FYI, I implemented the proposal, which I've described below re. the
modelling of likeable association statements[1,2] and updated also the
playlist example[3].

Cheers,


Bob

[1] http://smiy.sourceforge.net/ao/rdf/associationontology.n3
[2] http://smiy.sourceforge.net/ao/rdf/associationontology.owl
[3] http://smiy.sourceforge.net/pbo/examples/N3/playlist_-_example.n3

Kurt J

unread,
Jul 21, 2010, 6:18:21 PM7/21/10
to music-ontology-sp...@googlegroups.com
Hi Mr. Ferris,

[snip]

>>> I don't whether we can also adapt sim:subject for this relation. However,
>>> as
>>> far as I've understood the intend of this property, it should be used in
>>> combination with sim:object, or?
>>
>> yes these are more specific and relate to a directed sim:Association
>>
>
> What about the follow example (taken from my playlist example and extended):
>
> ex:ZazisAssociation a sim:Association ;
>        dc:creator <http://foaf.me/zazi#me> ;
>        sim:subject ex:Playlist ;
>        ao:genre "Funk" ;
>        ao:mood "party" ;
>        ao:occasion "my birthday party 2008" .

so you are trying to establish that "Funk" and "party" are associated?
and this association is the basis for ex:Playlist ???

recall that sim:Association is like rdf:Statement (altho it is not a
subclassOf) in that it is reified by providing either a sim:subject
and a sim:object (directed) or a series of sim:elemet (undirected).
this needs to be more clearly reflected in the musim ontology.

> From my point of view, this expresses the same as:
>
> ex:ZazisAssociation a sim:Association ;
>        dc:creator <http://foaf.me/zazi#me> ;
>        ao:genre "Funk" ;
>        ao:mood "party" ;
>        ao:occasion "my birthday party 2008" .
>
> ex:Playlist a pbo:Playlist ;
>        sim:association ex:ZazisAssociation .
>
> In both examples ex:Playlist is the subject of its association statement
> ex:ZazisAssociation, or? Furthermore, ao:genre, ao:mood and a:occasion could
> be also seen as sub properties of sim:object (maybe) ;)

perhaps you mean that _all_ items in ex:PlayList are associated to
eachother b/c they are genre "Funk" and mood "party"???

in this case perhaps you're after a property like sim:elements a
plural for of sim:element ??? or perhaps simply sim:element works
pointing to a collection.

in the modeling i intended, it doesn't really make sense to have a
sim:Association with a sim:subject and no sim:object. i need to make
this explicit in the modeling.

sim:Association a rdfs:Class;
owl:unionOf ( [a owl:Restriction;
owl:onProperty sim:elemet;
owl:minCardinality "2" ]
[ owl:intersectionOf ( [a owl:Restriction;
owl:onProperty sim:subject;
owl:minCardinality "1"^^xsd:nonNegativeInteger ]
[a owl:Restriction;
owl:onProperty sim:object;
owl:minCardinality "1"^^xsd:nonNegativeInteger ] ) ]
);

i think that mess does it.

make sense?

i think you mean that

ao:genere rdfs:subPropertyOf sim:element .
ao:mood rds:subPropertyOf sim:element .

if i understand, this would bring your examples in line with what I
_intended_ in the musim ontology :-)

-kurt j

Bob Ferris

unread,
Jul 22, 2010, 4:38:51 AM7/22/10
to music-ontology-sp...@googlegroups.com
Hi Kurt,

Am 22.07.2010 00:18, schrieb Kurt J:
> Hi Mr. Ferris,
>
> [snip]
>
>>>> I don't whether we can also adapt sim:subject for this relation. However,
>>>> as
>>>> far as I've understood the intend of this property, it should be used in
>>>> combination with sim:object, or?
>>>
>>> yes these are more specific and relate to a directed sim:Association
>>>
>>
>> What about the follow example (taken from my playlist example and extended):
>>
>> ex:ZazisAssociation a sim:Association ;
>> dc:creator<http://foaf.me/zazi#me> ;
>> sim:subject ex:Playlist ;
>> ao:genre "Funk" ;
>> ao:mood "party" ;
>> ao:occasion "my birthday party 2008" .
>
> so you are trying to establish that "Funk" and "party" are associated?
> and this association is the basis for ex:Playlist ???
>
> recall that sim:Association is like rdf:Statement (altho it is not a
> subclassOf) in that it is reified by providing either a sim:subject
> and a sim:object (directed) or a series of sim:elemet (undirected).
> this needs to be more clearly reflected in the musim ontology.

Yes, I'm aware of this. However, I also end up with the same result by
including this description into my thoughts ;)

>
>> From my point of view, this expresses the same as:
>>
>> ex:ZazisAssociation a sim:Association ;
>> dc:creator<http://foaf.me/zazi#me> ;
>> ao:genre "Funk" ;
>> ao:mood "party" ;
>> ao:occasion "my birthday party 2008" .
>>
>> ex:Playlist a pbo:Playlist ;
>> sim:association ex:ZazisAssociation .
>>
>> In both examples ex:Playlist is the subject of its association statement
>> ex:ZazisAssociation, or? Furthermore, ao:genre, ao:mood and a:occasion could
>> be also seen as sub properties of sim:object (maybe) ;)
>
> perhaps you mean that _all_ items in ex:PlayList are associated to
> eachother b/c they are genre "Funk" and mood "party"???

Yes, these associations/categorisations/descriptions should be used to
explain the content of a playlist and the intend behind their creation.
They are also only examples, one could use, of course, more different
domain descriptions.
That's why, I created all these property as sub property of
dcterms:subject ("The topic of the resource." + "Typically, the subject
will be represented using keywords, key phrases, or classification
codes. Recommended best practice is to use a controlled vocabulary."),
because all these properties are related to a specific domain (genre,
mood, occasion).

>
> in this case perhaps you're after a property like sim:elements a
> plural for of sim:element ??? or perhaps simply sim:element works
> pointing to a collection.

If I do this, they will loose their independency from the Similarity
Ontology. They are indented as super property of their domain ;)
Okay, one could create sub properties from them, which have as
rdfs:domain sim:Association. However, that would make other
subpropertying more difficult. As my initial intend was, e.g. mo:genre
rdfs:subPropertyOf ao:genre etc.

>
> in the modeling i intended, it doesn't really make sense to have a
> sim:Association with a sim:subject and no sim:object.

In that case, my properties ao:genre, ao:mood and ao:occasion would
maybe sub properties of sim:object.

> i need to make
> this explicit in the modeling.
>
> sim:Association a rdfs:Class;
> owl:unionOf ( [a owl:Restriction;
> owl:onProperty sim:elemet;
> owl:minCardinality "2" ]
> [ owl:intersectionOf ( [a owl:Restriction;
> owl:onProperty sim:subject;
> owl:minCardinality "1"^^xsd:nonNegativeInteger ]
> [a owl:Restriction;
> owl:onProperty sim:object;
> owl:minCardinality "1"^^xsd:nonNegativeInteger ] ) ]
> );
>
> i think that mess does it.
>
> make sense?
>

Woha, that's a complex restriction. Never saw such a nested thing before ;)
I can't really say, whether it is right or wrong. However, I understand
the intend behind these restrictions.

Yes, as described above. However, I'm unsure about the subpropertying
(see my reasons above).

Cheers,


Bob

Bob Ferris

unread,
Jul 22, 2010, 6:09:51 PM7/22/10
to music-ontology-sp...@googlegroups.com
Hi,

a small update re. the Association Ontology. I published now

http://purl.org/ontology/ao/annotationontology.html

However, I noticed that I'm now in conflict with the new restrictions of
sim:Association. I think, it wouldn't be good, when I mark ao:genre,
ao:mood and ao:occasion as sub properties of sim:element, because they
should also usable outside of sim:Association.
My proposal is now to substitute sim:element with dcterms:subject ;)


Does this makes sense? Could we come up with a solution, which fits both
intentions? - This and more in the next episode of Ontology Alignment
2010 :D

Cheers,


Bob

Kurt J

unread,
Jul 23, 2010, 9:36:44 AM7/23/10
to music-ontology-sp...@googlegroups.com
Hello,

I've decided to just lift the restrictions and keep a comment that
"generally" sim:Association "should" have the cardinality previously
specified, but it is not a requirement and it's not in the model.

So you're free. Free as a bird.


> a small update re. the Association Ontology. I published now
>
> http://purl.org/ontology/ao/annotationontology.html
>

btw, the above 404s for me?

-kurt j

Bob Ferris

unread,
Jul 23, 2010, 9:54:40 AM7/23/10
to music-ontology-sp...@googlegroups.com

No, it was a wrong link, there right one is here:

http://purl.org/ontology/ao/associationontology.html

Sorry for that.

Cheers,


Bob

Bob Ferris

unread,
Jul 25, 2010, 2:03:14 PM7/25/10
to music-ontology-sp...@googlegroups.com
Hello,

more good news ;)

I've created the Play Back Ontology Specification today:

http://purl.org/ontology/pbo/playbackontology.html

incl. examples of:

- a music playlist with association statements
- play back and skip counter of a music track

Please let me know, what do you think about this modelling. I feel now
more or less comfortable with it (after many re-modellings ;) ).

Cheers,


Bob

Kurt J

unread,
Jul 25, 2010, 2:51:26 PM7/25/10
to music-ontology-sp...@googlegroups.com
Hi Bobby,

Good stuff. I need to switch to using your specgen6 - pretty slick!

I like the examples. One question: I brought up the idea of modeling
playlist _transitions_ in some previous post. Is this possible in
pbo? For example, suppose the playlist in question is really a
beat-matched DJ mix, perhaps with some abrupt tempo changes that are
not beat-matched as well. Could I model something like:

:BeatMatchable a sim:AssociationMethod ;
dc:description "association between songs with close tempos and
compatible rhythms" .

:ABeatMatch a sim:Association;
sim:element :track01;
sim:element :track02;
sim:method :BeatMatchable.

:DistinctTempo a sim:AssociationMethod;
dc:description "stylistically similar but clearly distinct tempos" .

:TempoChange a sim:Association;
sim:element :track02;
sim:element :track03;
sim:method :DistinctTempo .

:Playlist a pbo:Playlist;
pbo:playlist_slot [
olo:index 1 ;
pbo:playlist_item :track01;
] ;
pbo:playlist_slot [
olo:index 2 ;
pbo:playlist_item :track02;
] ;
pbo:playlist_slot[
olo:index 3 ;
pbo:playlist_item :track03
].

# not sure how to bind these to playlist ???
:transition01 sim:association :ABeatMatch ;
pbo:start_slot [olo:index 1] ;
pbo:end_slot [olo:index 2] .
:transition02 sim:association :TempoChange ;
pbo:start_slot [olo:index 2] ;
pbo:end_slot [olo:index 3] .

Make any sense? Or are such things beyond the pbo scope? Plz note
the pbo:start_slot is something i just made up and that's a horrible
name for a property...

-kurt j

Bob Ferris

unread,
Jul 25, 2010, 5:02:54 PM7/25/10
to music-ontology-sp...@googlegroups.com
Hi Kurt,

nice use case ;)

In general my initial idea was to simply add all related association
statements (incl. similarity statements) directly to the playlist. That
means

:Playlist sim:association :AssociationStatement1
:Playlist sim:association :AssociationStatement2
:Playlist sim:association :AssociationStatement3

Am 25.07.2010 20:51, schrieb Kurt J:
> Hi Bobby,
>
> Good stuff. I need to switch to using your specgen6 - pretty slick!

Oh, it's no magic ;)
Currently, only concepts and properties are generated. Everything else
is manually added in the template, e.g. the whole owl:Ontology statement.

For this use case one could maybe use the pbo:PlaylistSlot concept and
add a property pbo:transition, which is a sub property of
sim:association and describes explicitly the association statement for
transition between this and the next (olo:next) playlist item.
So for the example above it could look like this here:

:Playlist a pbo:Playlist;
pbo:playlist_slot [

pbo:transition :ABeatMatch ;


olo:index 1 ;
pbo:playlist_item :track01;
] ;
pbo:playlist_slot [
olo:index 2 ;

pbo:transition :TempoChange ;


pbo:playlist_item :track02;
] ;
pbo:playlist_slot[
olo:index 3 ;
pbo:playlist_item :track03
].

However, I don't know really how to make sure all related constraints.
Maybe one cold create rules for these issues. Furthermore, this would
only describe the transition to the next playlist item. I don't no
really how to resolve another range issue here. maybe simply adapting
your proposal:

:Playlist sim:association [
pbo:beginning 1 ;
pbo:end 3 ;
sim:method :BeatMatchable ] .

Another method are named graphs, which could generally be applied to all
the annotation/association stuff. For this concrete use case, one has to
add a named graph on the property olo:next.

To continue the idea about the pbo:PlaylistSlot extension: one can
create a music specific sub class from this concept and create another
property that is based on sim:association, e.g. pbo:modification. This
could be the relation to all modifications, which were performed during
this replay of the related music track, e.g. tempo change. So if one
need it, one could add also that modified music track to the playlist
slot, e.g. pbo:modified_version.

I have to think a bit more about this use case, which seems very
interesting for DJs ;)

Thanks a lot for you feedback.

Cheers,


Bob

Bob Ferris

unread,
Jul 26, 2010, 2:10:28 PM7/26/10
to music-ontology-sp...@googlegroups.com
Hi,

what do you think about an alignment of the Association/Similarity
Ontology to the Tag Ontology[1]? The concepts of tags:Tagging and
sim:Association/ao:LikeableAssociation are somehow similar. However
tagging is tagging and association as proposed in the association
ontology are more like categorisations. However, could we really benefit
from them, or tags are enough?

Cheers,


Bob

[1] http://www.holygoat.co.uk/projects/tags/

Kurt J

unread,
Jul 26, 2010, 2:18:35 PM7/26/10
to music-ontology-sp...@googlegroups.com
Hello,

> what do you think about an alignment of the Association/Similarity Ontology
> to the Tag Ontology[1]? The concepts of tags:Tagging and
> sim:Association/ao:LikeableAssociation are somehow similar. However tagging
> is tagging and association as proposed in the association ontology are more
> like categorisations.

in my mind a tags:Tagging would be a subclass of sim:Association as it
is a special type of association between some entity and a tag. But
then tags:Tagging would get all the properties of a sim:Association
which might not make sense (not sure).

what alignment do you purpose?

> However, could we really benefit from them, or tags
> are enough?

yeah, I'm not sure what this alignment offers.

Bob Ferris

unread,
Jul 26, 2010, 2:36:49 PM7/26/10
to music-ontology-sp...@googlegroups.com
Hi Kurt,

Am 26.07.2010 20:18, schrieb Kurt J:
> Hello,
>
>> what do you think about an alignment of the Association/Similarity Ontology
>> to the Tag Ontology[1]? The concepts of tags:Tagging and
>> sim:Association/ao:LikeableAssociation are somehow similar. However tagging
>> is tagging and association as proposed in the association ontology are more
>> like categorisations.
>
> in my mind a tags:Tagging would be a subclass of sim:Association as it
> is a special type of association between some entity and a tag. But
> then tags:Tagging would get all the properties of a sim:Association
> which might not make sense (not sure).
>
> what alignment do you purpose?
>

Yes, my only thought was also that tags:Tagging could be a specific
association ;)
Well the intend behind this alignment is, that association/annotation
and tagging are all somehow similar to each other. The Tag Ontology
exists now also for about appr. 5 years and is more or less well know
(in the semantic web community). Hence, this ontology might be applied
somewhere (MOAT etc.).

What about a common super class ex:Annotation for sim:Association and
tag:Tagging. sim:Association are for more detail descriptions, e.g.
similarity statements or association statements for categorization.
tags:Tagging are for simple annotations.

>> However, could we really benefit from them, or tags
>> are enough?
>
> yeah, I'm not sure what this alignment offers.

Oh, I mean here benefit from specific categorizations rather than simple
tags. Although one can also add meaning to this tags (MOAT), but the
other way around as it is proposed in the association statement example
for categorization[1], produces probably a bit more meaning directly and
hence knowledge.

However, I'm unsure. It was just an idea, because the mechanism for
personalizations are looking quite equal and the domain is also more or
less the same ;)

Let's keep the idea some and feedback :)

Cheers,


Bob


[1] http://purl.org/ontology/ao/associationontology.html#sec-example

za...@elbklang.net

unread,
Jul 27, 2010, 6:32:19 PM7/27/10
to music-ontology-sp...@googlegroups.com
Hello,

I updated the Play Back Ontology today to version 0.5. There are only
minor changes to the previous version. I added:

- pbo:SkipEvent - a specific skip event of something; a sub class of
co:ScrobbleEvent
- pbo:skip_time - the moment, when someone skipped the media object, e.g.
an instant of a timeline of an audio signal

Please see also the related example[1] in the specification for details.

Cheers,


Bob


[1]
http://purl.org/ontology/pbo/playbackontology.html#sec-extended-skip-counter-example


Reply all
Reply to author
Forward
0 new messages