status of the mo:Playlist concept
Kurt J
I'm thinking about modeling play lists in RDF and I've come across a
mention of the mo:Playlist concept on the wiki [1]. Is there any more
information about this somewhere?
My thoughts are something like this:
mo:Playlist rdfs:subClassOf rdf:List .
:SexMachine a mo:Track .
:GoodFoot a mo:Track .
:FunkyPlaylist a mo:Playlist ;
rdf:first :SexMachine ;
rdf:rest _:FunkyPlaylist01 ;
mo:playlist_justification :JamesBrownGraph .
_:FunkyPlaylist01 a mo:Playlist;
rdf:first :GoodFoot ;
rdf:rest _:FunkyPlaylist02 .
:JamesBrownGraph = {
:SexMachine foaf:maker :JamesBrown.
:GoodFoot foaf:maker :JamesBrown.
}
So here we just are creating a list of mo:Tracks using the rdf:List
model. We add some detail with the mo:playlist_justification
property. This points to a graph that contains a set of triples that
show how the two tracks in that particular step of the playlist are
connected. In the above example the first two track are both made by
:JamesBrown.
I think mo:playlist_justification is a horrible name for this property
and perhaps this isn't the best way to model this. Hopefully my
intent is clear enough. Any suggestions on this???
-kurt j
Kurt J
Just a point of clarification - my intent is that
mo:playlist_justification applies to only one step in the playllist.
Each step in the playlist is associated with a set of triples that
"explains" the playlist. Perhaps there is a different property that
describes the global theme of the entire playlist.
Anxiously awaiting your thoughts :-)
-Kurt J
Bob Ferris
this is more or less the same issue I (should) currently work on. You
maybe followed the never ending discussion re. using rdf:List for
defining list [1]. Hence, it is somehow a critical design decision on
how to do that. There is also a OWL based list pattern[2] out there.
Furthermore, there is bibo:Collection[3] available, which propagates to
use dcterms:hasPart[4] and dcterms:isPartOf[5]. Furthermore in SIOC
exists also a concept called sioc:Playlist[6], which could maybe related
to the planed "mo:Playlist" concept.
I don't really like the rdf;List modelling in the described example,
because you define every time a new mo:Playlist, but what are really
doing is to define a new 'playlist item', which should be a part of the
whole playlist.
A further modelling aspect re. playlists is, to model (track) sequences.
That means not only to say: "that is a sequence of tracks", but "that is
a sequence of tracks, which should be kept together, when the playlist
engine automatically creates a playlist etc." (maybe also modelling the
reason why they should be kept together).
I think all these reasons:
- why one track in a playlist is similar to another one/ is followed by
another one
- why a sequence should be kept together
- ....
could be modelled with your Similarity Ontology ;)
Furthermore, I like to keep such a playlist concept/ontology media type
independent. That means, it should also be applicable for film, music
and X (are there more things one can play back?). Therefore, I think we
could also the Bibo Ontology or FRBR somehow, because they are already
defining different media types. I'm therefore currently also analyse the
reusability of the DC related ontologies.
Cheers,
Bob
PS: A very good interruption to focus on the real work ;)
[1]
http://old.nabble.com/What-is-it-that%27s-wrong-with-rdf%3AList-to28920391.html
[2] http://www.co-ode.org/ontologies/lists/2008/09/11/list.owl
[3]
http://bibotools.googlecode.com/svn/bibo-ontology/trunk/doc/classes/Collection___-1390642536.html
[4] http://dublincore.org/documents/dcmi-terms/index.shtml#terms-hasPart
[5] http://dublincore.org/documents/dcmi-terms/index.shtml#terms-isPartOf
[6] http://rdfs.org/sioc/types#Playlist
Kurt J
Thnx for your prompt and insightful reply.
> this is more or less the same issue I (should) currently work on. You maybe
> followed the never ending discussion re. using rdf:List for defining list
> [1]. Hence, it is somehow a critical design decision on how to do that.
> There is also a OWL based list pattern[2] out there.
> Furthermore, there is bibo:Collection[3] available, which propagates to use
> dcterms:hasPart[4] and dcterms:isPartOf[5]. Furthermore in SIOC exists also
> a concept called sioc:Playlist[6], which could maybe related to the planed
> "mo:Playlist" concept.
> I don't really like the rdf;List modelling in the described example, because
> you define every time a new mo:Playlist, but what are really doing is to
> define a new 'playlist item', which should be a part of the whole playlist.
creating a bunch of new mo:Playlists does seem sub-optimal but it
seems the big problem is the question "how long is the playlist" -
this is annoyingly tuff to answer using the rdf:first/rdf:rest
paradigm.
lots of good links - wasn't aware of sioc:Playlist but there isn't
much info on how it might be used as far as i can see. is there any
more info?
so i'm convinced rdf:List isn't all that great but i'm not convinced
there's a better way to do it :/
> A further modelling aspect re. playlists is, to model (track) sequences.
> That means not only to say: "that is a sequence of tracks", but "that is a
> sequence of tracks, which should be kept together, when the playlist engine
> automatically creates a playlist etc." (maybe also modelling the reason why
> they should be kept together).
> I think all these reasons:
> - why one track in a playlist is similar to another one/ is followed by
> another one
> - why a sequence should be kept together
> - ....
> could be modelled with your Similarity Ontology ;)
yes this is what i'm after - a "semantic playlist" that is is full of
supporting info - in my previous example the mo:playlist_justification
would probably point to a sim:Similarity rather than directly to a
graph.
but i feel we need additional concepts. we could define a MuSim playlist like:
:Playlist a sim:Similarity;
sim:element :Track0;
sim:element :Track1;
sim:element :Track2;
sim:element :Track3.... etc
But we have no explicit ordering here.
> Furthermore, I like to keep such a playlist concept/ontology media type
> independent. That means, it should also be applicable for film, music and X
> (are there more things one can play back?). Therefore, I think we could also
> the Bibo Ontology or FRBR somehow, because they are already defining
> different media types. I'm therefore currently also analyse the reusability
> of the DC related ontologies.
fair enough - perhaps the Playlist concept is more appropriate in the
SIOC vocab or something.
Is there an example of how the sioc:Playist is meant to be used???
-kurt j
Yves Raimond
> I'm thinking about modeling play lists in RDF and I've come across a
> mention of the mo:Playlist concept on the wiki [1]. Is there any more
> information about this somewhere?
>
> My thoughts are something like this:
>
> mo:Playlist rdfs:subClassOf rdf:List .
Hmm, not sure about that - I think it should be modeled in a similar
way as the album/track relationship. Ultimately, you'd just want a
mo:Playlist concept that is exactly at the same ontological level as
mo:Record.
:ex a mo:Playlist .
:sex_machine a mo:Track ; mo:track_number 1.
:good_foot a mo:Track; mo:track_number 2.
No need for rdf:List if you use mo:Track...
>
> :SexMachine a mo:Track .
> :GoodFoot a mo:Track .
>
> :FunkyPlaylist a mo:Playlist ;
> rdf:first :SexMachine ;
> rdf:rest _:FunkyPlaylist01 ;
> mo:playlist_justification :JamesBrownGraph .
>
> _:FunkyPlaylist01 a mo:Playlist;
> rdf:first :GoodFoot ;
> rdf:rest _:FunkyPlaylist02 .
>
> :JamesBrownGraph = {
> :SexMachine foaf:maker :JamesBrown.
> :GoodFoot foaf:maker :JamesBrown.
> }
>
> So here we just are creating a list of mo:Tracks using the rdf:List
> model. We add some detail with the mo:playlist_justification
> property. This points to a graph that contains a set of triples that
> show how the two tracks in that particular step of the playlist are
> connected. In the above example the first two track are both made by
> :JamesBrown.
I don't think you need playlist_justification here - can't you just
add the statements necessary to draw that connection?
:ex a mo:Playlist .
:sex_machine a mo:Track ; mo:track_number 1; foaf:maker :james_brown .
:good_foot a mo:Track; mo:track_number 2; foaf:maker :james_brown .
Cheers,
y
>
> I think mo:playlist_justification is a horrible name for this property
> and perhaps this isn't the best way to model this. Hopefully my
> intent is clear enough. Any suggestions on this???
>
> -kurt j
>
> [1] - http://wiki.musicontology.com/index.php/Todo_list
>
> --
> 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.
>
>
Kurt J
>> I'm thinking about modeling play lists in RDF and I've come across a
>> mention of the mo:Playlist concept on the wiki [1]. Is there any more
>> information about this somewhere?
>>
>> My thoughts are something like this:
>>
>> mo:Playlist rdfs:subClassOf rdf:List .
>
> Hmm, not sure about that - I think it should be modeled in a similar
> way as the album/track relationship. Ultimately, you'd just want a
> mo:Playlist concept that is exactly at the same ontological level as
> mo:Record.
>
> :ex a mo:Playlist .
> :sex_machine a mo:Track ; mo:track_number 1.
> :good_foot a mo:Track; mo:track_number 2.
>
> No need for rdf:List if you use mo:Track...
i'm not so sure. what is :sex_machine is associated with a mo:Record
and has a mo:track_number for that and is also associated with a
mo:Playlist and has a mo:track_number for that. This seems ambiguous.
do we add mo:playlist_number ??? but then when :sex_machine appears
in multiple playlists at different positions, what do we do???
>>
>> :SexMachine a mo:Track .
>> :GoodFoot a mo:Track .
>>
>> :FunkyPlaylist a mo:Playlist ;
>> rdf:first :SexMachine ;
>> rdf:rest _:FunkyPlaylist01 ;
>> mo:playlist_justification :JamesBrownGraph .
>>
>> _:FunkyPlaylist01 a mo:Playlist;
>> rdf:first :GoodFoot ;
>> rdf:rest _:FunkyPlaylist02 .
>>
>> :JamesBrownGraph = {
>> :SexMachine foaf:maker :JamesBrown.
>> :GoodFoot foaf:maker :JamesBrown.
>> }
>>
>> So here we just are creating a list of mo:Tracks using the rdf:List
>> model. We add some detail with the mo:playlist_justification
>> property. This points to a graph that contains a set of triples that
>> show how the two tracks in that particular step of the playlist are
>> connected. In the above example the first two track are both made by
>> :JamesBrown.
>
> I don't think you need playlist_justification here - can't you just
> add the statements necessary to draw that connection?
>
> :ex a mo:Playlist .
> :sex_machine a mo:Track ; mo:track_number 1; foaf:maker :james_brown .
> :good_foot a mo:Track; mo:track_number 2; foaf:maker :james_brown .
for this particular simple connection, no it's not required. however,
consider there are a potentially infinite number of justifications for
two tracks to be adjacent in a playlist. this was just a very very
simple example. you might want to say something like, "these tracks
follow each other on the playlist because they have nearly equivalent
BPM values" or something quite complicated like, "these tracks follow
each other on the playlist because they are both by artists who
converted to Islam"
of the potentially infinite number of connections between two
mo:Tracks - we want to specify one specific path that was used as the
inspiration for the creation of a particular playlist.
does that make sense? or am i trying to do something that is utterly
pedantic and boring? ;-)
Bob Ferris
Am 26.06.2010 19:42, schrieb Kurt J:
> Hi Bob,
>
> Thnx for your prompt and insightful reply.
>
>> this is more or less the same issue I (should) currently work on. You maybe
>> followed the never ending discussion re. using rdf:List for defining list
>> [1]. Hence, it is somehow a critical design decision on how to do that.
>> There is also a OWL based list pattern[2] out there.
>> Furthermore, there is bibo:Collection[3] available, which propagates to use
>> dcterms:hasPart[4] and dcterms:isPartOf[5]. Furthermore in SIOC exists also
>> a concept called sioc:Playlist[6], which could maybe related to the planed
>> "mo:Playlist" concept.
>> I don't really like the rdf;List modelling in the described example, because
>> you define every time a new mo:Playlist, but what are really doing is to
>> define a new 'playlist item', which should be a part of the whole playlist.
>
> creating a bunch of new mo:Playlists does seem sub-optimal but it
> seems the big problem is the question "how long is the playlist" -
> this is annoyingly tuff to answer using the rdf:first/rdf:rest
> paradigm.
Yes, I think sometimes we need a concatenated list with 'previous' and
'next' properties (I often see only a next property defined). I think
there are two main use cases in playlist usage:
1) On the one side, when a playlist will be created, it has in general a
fixed size at the end. That means, when this playlist will be stored in
the database/knowledge base, we know its size. If we change something,
then the whole playlist graph should be rewriten or new graph will be
created.
2) On the other side, there might be use case for endless playlist, e.g.
when idiosyncratic genre definitions are used as general playlist
template. However, also this use case is getting now a bit clearer in my
mind. Then there is also a fixed size at the beginning and when the end
of the playlist is reached and the user has enabled the option for
endless playlists, the existing playlist will only be extend by a
specific number of tracks. So we reached the state of use case 1) the
playlist graph will be rewritten or new created in the knowledge base.
>
> lots of good links - wasn't aware of sioc:Playlist but there isn't
> much info on how it might be used as far as i can see. is there any
> more info?
As far as I've figured it out, it is only a SIOC type, so it more a hook
for further playlist definitions.
>
> so i'm convinced rdf:List isn't all that great but i'm not convinced
> there's a better way to do it :/
>
>> A further modelling aspect re. playlists is, to model (track) sequences.
>> That means not only to say: "that is a sequence of tracks", but "that is a
>> sequence of tracks, which should be kept together, when the playlist engine
>> automatically creates a playlist etc." (maybe also modelling the reason why
>> they should be kept together).
>> I think all these reasons:
>> - why one track in a playlist is similar to another one/ is followed by
>> another one
>> - why a sequence should be kept together
>> - ....
>> could be modelled with your Similarity Ontology ;)
>
>
> yes this is what i'm after - a "semantic playlist" that is is full of
> supporting info - in my previous example the mo:playlist_justification
> would probably point to a sim:Similarity rather than directly to a
> graph.
Wasn't there already a property in MO to relate to a sim:Similarity graph?
>
> but i feel we need additional concepts. we could define a MuSim playlist like:
>
> :Playlist a sim:Similarity;
> sim:element :Track0;
> sim:element :Track1;
> sim:element :Track2;
> sim:element :Track3.... etc
>
> But we have no explicit ordering here.
The similarity definitions are somehow orthogonal to the order in the
playlist. That's means you could define
- a similarity description of two neighbouring tracks
- a similarity description of track A in the playlist to track B in the
playlist
- a similarity description of a track set A in the playlist to a track
set B in the playlist
>
>> Furthermore, I like to keep such a playlist concept/ontology media type
>> independent. That means, it should also be applicable for film, music and X
>> (are there more things one can play back?). Therefore, I think we could also
>> the Bibo Ontology or FRBR somehow, because they are already defining
>> different media types. I'm therefore currently also analyse the reusability
>> of the DC related ontologies.
>
> fair enough - perhaps the Playlist concept is more appropriate in the
> SIOC vocab or something.
>
> Is there an example of how the sioc:Playist is meant to be used???
As mentioned above, I think this concept is only a hook for a real
defined playlist concept.
Cheers,
Bob
PS: the Bibo Ontology makes also use of rdf:List and rdf:Seq etc.
Bob Ferris
Am 26.06.2010 20:55, schrieb Yves Raimond:
> Hello!
>
>> I'm thinking about modeling play lists in RDF and I've come across a
>> mention of the mo:Playlist concept on the wiki [1]. Is there any more
>> information about this somewhere?
>>
>> My thoughts are something like this:
>>
>> mo:Playlist rdfs:subClassOf rdf:List .
>
> Hmm, not sure about that - I think it should be modeled in a similar
> way as the album/track relationship. Ultimately, you'd just want a
> mo:Playlist concept that is exactly at the same ontological level as
> mo:Record.
>
> :ex a mo:Playlist .
> :sex_machine a mo:Track ; mo:track_number 1.
> :good_foot a mo:Track; mo:track_number 2.
>
> No need for rdf:List if you use mo:Track...
>
I would currently also propagate this modelling pattern, as explained in
my previous email to the mailing list. Of course, it is static, that
means it has at the end a fixed playlist size and a concrete ordering,
but as already mentioned, if a user would change something re. these
settings, then the playlist graph will be written new or rewritten in
the knowledge base.
>
>>
>> :SexMachine a mo:Track .
>> :GoodFoot a mo:Track .
>>
>> :FunkyPlaylist a mo:Playlist ;
>> rdf:first :SexMachine ;
>> rdf:rest _:FunkyPlaylist01 ;
>> mo:playlist_justification :JamesBrownGraph .
>>
>> _:FunkyPlaylist01 a mo:Playlist;
>> rdf:first :GoodFoot ;
>> rdf:rest _:FunkyPlaylist02 .
>>
>> :JamesBrownGraph = {
>> :SexMachine foaf:maker :JamesBrown.
>> :GoodFoot foaf:maker :JamesBrown.
>> }
>>
>> So here we just are creating a list of mo:Tracks using the rdf:List
>> model. We add some detail with the mo:playlist_justification
>> property. This points to a graph that contains a set of triples that
>> show how the two tracks in that particular step of the playlist are
>> connected. In the above example the first two track are both made by
>> :JamesBrown.
>
> I don't think you need playlist_justification here - can't you just
> add the statements necessary to draw that connection?
>
> :ex a mo:Playlist .
> :sex_machine a mo:Track ; mo:track_number 1; foaf:maker :james_brown .
> :good_foot a mo:Track; mo:track_number 2; foaf:maker :james_brown .
>
No, yvesr, I think similarity relations could be somehow complex
sometimes, please remember DBRec[1]. That's why I would propagate the
usage of a sim:Similarity based description. Furthermore, I don't want
to add explicitly information like e.g. foaf:maker, which could be
reached through the properties of the mo:Track instance. I would simple
add these information to the similarity description, which are
responsible for this similarity.
Cheers,
Bob
Yves Raimond
>
>>> I'm thinking about modeling play lists in RDF and I've come across a
>>> mention of the mo:Playlist concept on the wiki [1]. Is there any more
>>> information about this somewhere?
>>>
>>> My thoughts are something like this:
>>>
>>> mo:Playlist rdfs:subClassOf rdf:List .
>>
>> Hmm, not sure about that - I think it should be modeled in a similar
>> way as the album/track relationship. Ultimately, you'd just want a
>> mo:Playlist concept that is exactly at the same ontological level as
>> mo:Record.
>>
>> :ex a mo:Playlist .
>> :sex_machine a mo:Track ; mo:track_number 1.
>> :good_foot a mo:Track; mo:track_number 2.
>>
>> No need for rdf:List if you use mo:Track...
>
> i'm not so sure. what is :sex_machine is associated with a mo:Record
> and has a mo:track_number for that and is also associated with a
> mo:Playlist and has a mo:track_number for that. This seems ambiguous.
> do we add mo:playlist_number ??? but then when :sex_machine appears
> in multiple playlists at different positions, what do we do???
Well, that's the whole purpose of mo:Signal - the canonical track,
that can be shared across many records/playlists/etc. (this is the way
it is modeled in the XSPF/MO XSLT, btw). A mo:Track is a track on a
particular record/tracklist.
But isn't the same thing possible in both those cases?
:ex a mo:Playlist .
:track1 a mo:Track; mo:track_number 1; mo:bpm 123.
:track2 a mo:Track; mo:track_number 2; mo:bpm 125.
123 :close_enough 125.
:-)
(the Islam example is even simpler - just stating that the tracks have
a foaf:maker that is :converted_to Islam?)
Cheers,
y
>
> of the potentially infinite number of connections between two
> mo:Tracks - we want to specify one specific path that was used as the
> inspiration for the creation of a particular playlist.
>
> does that make sense? or am i trying to do something that is utterly
> pedantic and boring? ;-)
>
Bob Ferris
> Hello!
>
>>> I'm thinking about modeling play lists in RDF and I've come across a
>>> mention of the mo:Playlist concept on the wiki [1]. Is there any more
>>> information about this somewhere?
>>>
>>> My thoughts are something like this:
>>>
>>> mo:Playlist rdfs:subClassOf rdf:List .
>>
>> Hmm, not sure about that - I think it should be modeled in a similar
>> way as the album/track relationship. Ultimately, you'd just want a
>> mo:Playlist concept that is exactly at the same ontological level as
>> mo:Record.
>>
>> :ex a mo:Playlist .
>> :sex_machine a mo:Track ; mo:track_number 1.
>> :good_foot a mo:Track; mo:track_number 2.
>>
>> No need for rdf:List if you use mo:Track...
>
> i'm not so sure. what is :sex_machine is associated with a mo:Record
> and has a mo:track_number for that and is also associated with a
> mo:Playlist and has a mo:track_number for that. This seems ambiguous.
> do we add mo:playlist_number ??? but then when :sex_machine appears
> in multiple playlists at different positions, what do we do???
maybe we could define a more general property, e.g. my_ns:set_number and
probably derive some more specific properties from there (if needed).
However, they expressing more or less every time the same - the ordering
in a set. Currently, I can remember mo:track_number, mo:record_number.
Now we need mo:playlist_number. I think there is a need for generalisation.
It's also the same issue with the 'count' properties. There is
mo:track_count and mo:record_count (as far as I can remember). Now we
need probably also mo:playlist_count. What about my_ns:count?
co:count is sematically a bit different I think, because it should be
realated to a counter somehow, and increases. my_ns:count is for the
beginning static.
No, I think you are one the right way - expressing multiple similarity
relations. That is added value!
Cheers,
Bob
Kurt J
>> so i'm convinced rdf:List isn't all that great but i'm not convinced
>> there's a better way to do it :/
>>
>>> A further modelling aspect re. playlists is, to model (track) sequences.
>>> That means not only to say: "that is a sequence of tracks", but "that is
>>> a
>>> sequence of tracks, which should be kept together, when the playlist
>>> engine
>>> automatically creates a playlist etc." (maybe also modelling the reason
>>> why
>>> they should be kept together).
>>> I think all these reasons:
>>> - why one track in a playlist is similar to another one/ is followed by
>>> another one
>>> - why a sequence should be kept together
>>> - ....
>>> could be modelled with your Similarity Ontology ;)
>>
>>
>> yes this is what i'm after - a "semantic playlist" that is is full of
>> supporting info - in my previous example the mo:playlist_justification
>> would probably point to a sim:Similarity rather than directly to a
>> graph.
>
> Wasn't there already a property in MO to relate to a sim:Similarity graph?
there is a property in MuSim for this - sim:grounding is meant to
point to an instantiated N3 (or N3-Tr) graph explaining a similarity.
>>
>> but i feel we need additional concepts. we could define a MuSim playlist
>> like:
>>
>> :Playlist a sim:Similarity;
>> sim:element :Track0;
>> sim:element :Track1;
>> sim:element :Track2;
>> sim:element :Track3.... etc
>>
>> But we have no explicit ordering here.
>
> The similarity definitions are somehow orthogonal to the order in the
> playlist. That's means you could define
> - a similarity description of two neighbouring tracks
> - a similarity description of track A in the playlist to track B in the
> playlist
> - a similarity description of a track set A in the playlist to a track set B
> in the playlist
ok, i think maybe this is a step forward perhaps.
If we're using MuSim, consider that we could define a Playlist as a
collection of directed similarity statements. In a sense our playlist
becomes a collection of _transitions_ between tracks rather than a
collection of tracks - this might appeal to the more DJ-minded people
for the sake of illustrating my point i'm creating a playlist ns "pl"
:MyPlaylist a pl:Playlist ;
pl:has_transition :transition00 .
:transition00 a sim:Similarity;
pl:transition_number 0;
sim:subject :Track00;
sim:object :Track01;
sim:grounding {:Track00 foaf:maker :JamesBronw . :Track01 foaf:maker
:JamesBrown . } .
is this a potentially fruitful direction or am i talking nonsense again?
Yves Raimond
Hmm. I am not sure I follow. An aggregated similarity measure (like
musim or the DBRec ontology) can also be explicitly stated - no need
for a 'justification graph' there? A simple example would be something
in the lines of:
:ex a mo:Playlist .
:track1 a mo:Track; mo:track_number 1.
:track2 a mo:Track; mo:track_number 2.
:track1 mo:similar_to :track2 . <-- insert your favorite similarity
reification concept here.
My point is just that you can make those statements explicit with the
playlist. If you want to cluster them into named graphs, fine, but I
don't think you need that playlist_justification property.
Cheers,
y
>
> Cheers,
>
>
> Bob
>
> [1] http://dbrec.net/
>
Yves Raimond
> Am 26.06.2010 21:27, schrieb Kurt J:
>>
>> Hello!
>>
>>>> I'm thinking about modeling play lists in RDF and I've come across a
>>>> mention of the mo:Playlist concept on the wiki [1]. Is there any more
>>>> information about this somewhere?
>>>>
>>>> My thoughts are something like this:
>>>>
>>>> mo:Playlist rdfs:subClassOf rdf:List .
>>>
>>> Hmm, not sure about that - I think it should be modeled in a similar
>>> way as the album/track relationship. Ultimately, you'd just want a
>>> mo:Playlist concept that is exactly at the same ontological level as
>>> mo:Record.
>>>
>>> :ex a mo:Playlist .
>>> :sex_machine a mo:Track ; mo:track_number 1.
>>> :good_foot a mo:Track; mo:track_number 2.
>>>
>>> No need for rdf:List if you use mo:Track...
>>
>> i'm not so sure. what is :sex_machine is associated with a mo:Record
>> and has a mo:track_number for that and is also associated with a
>> mo:Playlist and has a mo:track_number for that. This seems ambiguous.
>> do we add mo:playlist_number ??? but then when :sex_machine appears
>> in multiple playlists at different positions, what do we do???
>
I don't see why mo:track_number wouldn't suit the playlist use-case as
well - it is the number of a track in an unspecified container - so
deliberately fairly vague. That container can perfectly be a track or
a playlist.
Cheers,
y
Yves Raimond
> If we're using MuSim, consider that we could define a Playlist as a
> collection of directed similarity statements. In a sense our playlist
> becomes a collection of _transitions_ between tracks rather than a
> collection of tracks - this might appeal to the more DJ-minded people
>
> for the sake of illustrating my point i'm creating a playlist ns "pl"
>
> :MyPlaylist a pl:Playlist ;
> pl:has_transition :transition00 .
>
> :transition00 a sim:Similarity;
> pl:transition_number 0;
> sim:subject :Track00;
> sim:object :Track01;
> sim:grounding {:Track00 foaf:maker :JamesBronw . :Track01 foaf:maker
> :JamesBrown . } .
>
> is this a potentially fruitful direction or am i talking nonsense again?
I think it makes sense, but perhaps pushes the indirection too far for
something fairly simple (in that case). musim is more interesting to
me when the derived similarity is complex - e.g. combining editorial
and musical characteristics. I guess it all depends how you want to
use that data. If you want to provide an 'editorial' justification for
a playlist, then I think it makes sense to have it on the side and to
reify it so that you can state more about the editorial intention,
using any kind of suitable mechanism. If you just want to explain the
common points between two tracks, then just make it explicit through
simple statements (more statements about the artists, the track, etc.,
linking two tracks together by other means than the playlist itself).
The latter also ensure that additional knowledge is reusable easily in
other contexts.
Not sure if what I just wrote make sense - let me know if it doesn't :)
Cheers,
y
Kurt J
yes makes sense and i agree musim was originally intended for these
more complicated similarity derivation processes.
my vision is a semantic playlist that tells some story. and i have a
specific application in mind - i want to extend catfishsmooth such
that users build playlists where the connections they followed through
the music-linked-data world are recorded as they add songs to the
playlist. again, there any many potential paths between two elements
in a playlist but the user followed one particular path. i want to
record which path was followed.
perhaps this application had blinded me to proper way to model things.
Bob Ferris
I think, it is all about reusing these similarity descriptions, so that
I have an URI for my similarity description, which I can always use for
expressing these specific similarity description between two specific
tracks/track sets.
Furthermore I would propagate one 'best practice' for defining this
similarity descriptions (over similarity descriptions by using
sim:Similarity). It is somehow important today, to have an engine, which
could express similarity over the whole range of metadata, which is used
to describe something. That will be the added value - to combine
'easily' metadata concepts of all metadata categories in matter you want
to do it and not how the application dictates it to me.
Furthermore, I think the editorial part is another use case, which could
partly be covered by the similarity ontology, but there have to used
also other concepts, e.g. events and other relevant notes (maybe this
could also be covered by the similarity ontology, I had this somehow in
mind).
Cheers,
Bob
Yves Raimond
That sounds really interesting! I need to think a bit more about it
now :) I guess most of the work involved would be in uniquely
identifying the tracks and getting as much information as you can get
from the user's journey. Then, once you get enough data, you can mine
it to see what the common points between all these tracks are. I am
indeed not sure how to best record the fact that this is something
that you mined from a user's journey though...
y
>
> perhaps this application had blinded me to proper way to model things.
>
Kurt J
in my head, it's not nearly that clever :-)
catfishsmooth focuses on the granularity of _artists_ so in the first
iteration we're dealing simply at this level. Of course we'd want to
eventually get to the granularity of individual songs but in the first
iteration i think we just go there with foaf:maker and
mo:available_as. To get to the track level properly we'll need
somebody to do the NGS MusicBrainz mapping for starters (ahem).
consider that catfishsmooth is, in a sense, a faceted browser where
the only facet you can deal with is mo:MusicArtists (a poor man's
faceted browser). So each "click" the user makes is following a
specific path that can be defined by a series of triples.
For example, say i start at James Brown, see that Chuck Berry is also
a yago:IncarceratedCelebrity and follow that path, arbitrarily picking
my favorite James Brown track and then my favorite Chuck Berry track
to add to the playlist. In this playlist transition i'd want to bind
a graph like
{ :JamesBrown a yago:IncarceratedCelebrity ;
foaf:made [mo:available_as <http://youtube/clip1> ] .
:ChuckBerry a yago:IncarceratedCelebrity ;
foaf:made [mo:available_as <http://youtube/clip2> ] .
}
So it's all based on recording click thru data from the user. Of
course we'd like to have much more information about each track -
hopefully that all comes in the future...
One big hiccup i see is that a user would expect to have the ability
to re-arrange the order of a playlist. This would sort-of ruin my
whole idea!
-kurt j
mats...@gmail.com
Hello!Well, that's the whole purpose of mo:Signal - the canonical track,
>
>>> I'm thinking about modeling play lists in RDF and I've come across a
>>> mention of the mo:Playlist concept on the wiki [1]. Is there any more
>>> information about this somewhere?
>>>
>>> My thoughts are something like this:
>>>
>>> mo:Playlist rdfs:subClassOf rdf:List .
>>
>> Hmm, not sure about that - I think it should be modeled in a similar
>> way as the album/track relationship. Ultimately, you'd just want a
>> mo:Playlist concept that is exactly at the same ontological level as
>> mo:Record.
>>
>> :ex a mo:Playlist .
>> :sex_machine a mo:Track ; mo:track_number 1.
>> :good_foot a mo:Track; mo:track_number 2.
>>
>> No need for rdf:List if you use mo:Track...
>
> i'm not so sure. what is :sex_machine is associated with a mo:Record
> and has a mo:track_number for that and is also associated with a
> mo:Playlist and has a mo:track_number for that. This seems ambiguous.
> do we add mo:playlist_number ??? but then when :sex_machine appears
> in multiple playlists at different positions, what do we do???
that can be shared across many records/playlists/etc. (this is the way
it is modeled in the XSPF/MO XSLT, btw). A mo:Track is a track on a
particular record/tracklist.
Yves Raimond
Well, to do that, you certainly need three layers: the track,
regardless of the medium, the CD/Playlist, and the MP3/CD item. Those
three layers correspond to mo:Signal, mo:Track and mo:MusicalItem,
respectively.
:sex_machine a mo:Signal ; mo:published_as :sex_machine_on_playlist,
:sex_machine_on_album .
:sex_machine_on_playlist a mo:Track; mo:track_number 12 ;
mo:available_as <file.mp3> .
:sex_machine_on_record a mo:Track; mo:track_number 3 ; mo:available_as
<track.flac> .
etc.
y
> Cheers,
> Mats
Bob Ferris
Okay, how would you associate all similarity descriptions, which are
responsible for build a specific playlist? mo:similar_to explains only
that two things are similar.
sim:Similarity could explain how.
I am still for one 'best practice' (which is called sim:Similarity) for
similarity _descriptions_.
I would tend to association all relevant sim:Similarity instances, which
are used to create a playlist (if this playlist was created
automatically based on a kind of similarity). I don't know really if
sim:grounding fits this purpose.
Thereby, I mean all mentioned similarity relations:
<quote>
The similarity definitions are somehow orthogonal to the order in the
playlist. That's means you could define
- a similarity description of two neighbouring tracks
- a similarity description of track A in the playlist to track B in the
playlist
- a similarity description of a track set A in the playlist to a track
set B in the playlist
</quote>
Cheers,
Bob
Bob Ferris
fresh from the RDFNext Workshop - a proposal for ordered lists as
fundamental concept[1].
To fuel the discussion a bit ;)
Cheers,
Bob
PS: Think about predefined track sequences!
[1] http://www.w3.org/2009/12/rdf-ws/slides/rdflist.pdf
Samer Abdallah
It seems to me that is an example of the more general problem of how
to represent structured data in a language with only atomic values and
binary relations (like RDF). In languages with algebraic data types, it
would be very easy; eg in Prolog or Mercury, I would define a type
for lists of signals, like this
playlist ---> pl(signal, playlist_tail).
playlist_tail ---> plt(signal, justification, playlist_tail) ; nil.
then a particular list can be written as a single expression using the functors
pl/2, plt/3 and nil/0, eg
PL=pl( sex_machine, plt(good_foot, same_maker(sex_machine, good_foot), nil).
same_maker(A,B) :- maker(A,M), maker(B,M).
Here, I've assumed that justication is simply a proposition (eg a Prolog goal)
that is true and is an explanation of why this item follows the previous.
In Haskell, the data type would be:
data Playlist t = PL t (PlaylistTail t)
data PlaylistTail t = PLT t Justification PlaylistTail | PLTNil
where I've thrown in some polymorphism over the item type just for good
measure.
Clearly, the problem with RDF is that we can't write down compound terms
like plt( good_foot, its_tuesday, nil) but have to describe them in a reified
way using only binary relations. To do this in the most obvious and bloody
minded way is quite laborious (which reminds me of writing programs in
assembly language instead of a high level language), eg if
X=pl(sex_machine, plt(good_foot, its_tuesday, nil)) is a playlist, then:
functor(X, pl/2),
pl_head(X, sex_machine),
pl_rest(X, Y),
functor(Y, plt/3),
plt_head(Y, good_foot),
plt_justification(Y, its_tuesday),
plt_rest(Y, Z),
functor(Z, nil/0).
Here I've introduced a separate binary relation for each named slot of
each functor. This more or less corresponds to Kurt's initial suggestion,
except that the justification is attached to the *following* item rather
than the *preceding* one, which means that a playlist of one item needs
no justification. Also, according to my definition at the top, a playlist
must have at least on item. If we are being pedantic, then the class
structure implied by all this is quite involved: each constructor/functor
for each type is a separate class:
Root
Playlist (valid properties are head and rest)
PlaylistTail (NO properties)
PlaylistTail_PLT3 (props are head, justification and rest)
PlaylistTail_Nil (no properties)
NB, a playlist_tail is *not* a playlist, and the properties head, justification
and rest can only apply to the subclass PlaylistTail_PLT3 and not to the
class PlaylistTail. This means that logic inferences can work correctly
in an open world - a playlist reaches its end when we *know* that the
list item is a PlaylistTail_Nil, and not simply when we can't find any
'rest' property. In this particular case, we *could* collapse Playlist_PLT3
into PlaylistTail, eliminate Playlist_Nil, and have a special individual
playlist_tail_nil to denote an empty PlaylistTail (ie just like rdf:List and
rdf:nil), but in the more general case of an algebraic data type with more
than one constructor/functor with arguments, this option would not be
available. For example, if a Playlist could call another playlist like a
subroutine, with no justification required, then we would have an
algebraic type like this:
playlist_tail ---> plt( signal, justification, playlist_tail)
; inc( playlist, playlist_tail)
; nil.
In this case, we would need the two separate subclasses PlaylistTail2_PLT3
and PlaylistTail2_Inc2 because they would have different arguments/properties.
Kurt's 'how long is the playlist' question is answered easily enough
in Prolog form with pattern matching:
playlist_length(pl(_,PLT), N) :- playlist_tail_length(PLT, M), N is M+1.
playlist_tail_length(plt(_,_,PLT), N) :- playlist_tail_length(PLT, M), N is M+1.
playlist_tail_length(nil, 0).
but without pattern matching and using only binary predicates (ie RDF form)
as in the earlier example, it would be
% length of playlist
pl_length(PL, N) :-
functor(PL, pl/2),
pl_rest(PL,PLT),
plt_length(PLT, M),
N is M+1.
% length of playlist_tail
plt_length(PLT, 0) :- functor(PLT, nil/0).
plt_length(PLT1, N) :-
functor( PLT1, plt/3),
plt_rest( PLT1, PLT2),
plt_length(PLT2, M),
N is M+1.
So it's a bit fiddly but fairly mechanical.
Yves suggested using Track and track_number to model the sequence. This
would be an example of the more general idea of modelling a sequence as
as set of (index,item) pairs (ie a binary relation), but to do it here, we'd need
a *ternary* relation seq_index_item/3, where seq_index_item(Playlist, N, Thing)
means 'Thing is the Nth item in Playlist'. It has to be ternary because, as Kurt
pointed out, Thing might have a different index in a different sequence. We'd
need a new concept or class of a sequence 'slot', which will be a direct reification
of the ternary relation, eg (making up names freely on the fly..)
:FunkyPL a seq:Sequence;
seq:length 2.
_:FunkyPL_1 a seq:Slot;
seq:in_sequence :FunkyPL;
seq:index 1;
seq:item :SexMachine.
_:FunkyPL_2 a mo:PlaylistSlot;
seq:in_sequence :FunkyPL;
seq:index 2;
seq:item :GoodFoot.
My RDF writing skills are but weak but I think if seq:has_slot was defined as
an inverse property to seq:in_sequence, this could be written sort of like this:
:FunkyPL a seq:Sequence;
seq:length 2;
seq:has_slot {
seq:index 1;
seq:item :SexMachine
};
seq:has_slot {
seq:index 2;
seq:item :GoodFoot
}.
... which is almost readable.
The justification thing Kurt proposed could be attached to a sub-class
of seq:Slot, eg mo:PlaylistSlot, as long as seq:index > 1.
Going back to Yves' mention of Tracks and track_number, this
suggest that a Track plays the role of a seq:Slot for mo:Signals in the
context of the sequence defined by an album.
The reason I've gone on at such length about this is that it's by no
means an isolated problem - I started working with the chord ontology
recently and found the representation of notes and scale degrees problematic
precisely because it was not a faithful translation of the fairly straightforward
algebraic data types that one might define for such things, and indeed we
did define in our original paper on the subject (Harte, Sandler, Abdallah, Gómez,
2005; 'Symbolic Representation of Musical Chords: A Proposed Syntax for Text Annotations').
Well, I won't go on at length about that :)
Samer.
Yves Raimond
>
> It seems to me that is an example of the more general problem of how
> to represent structured data in a language with only atomic values and
> binary relations (like RDF). In languages with algebraic data types, it
> would be very easy; eg in Prolog or Mercury, I would define a type
> for lists of signals, like this
>
> playlist ---> pl(signal, playlist_tail).
> playlist_tail ---> plt(signal, justification, playlist_tail) ; nil.
>
> then a particular list can be written as a single expression using the functors
> pl/2, plt/3 and nil/0, eg
>
> PL=pl( sex_machine, plt(good_foot, same_maker(sex_machine, good_foot), nil).
> same_maker(A,B) :- maker(A,M), maker(B,M).
>
Yes, I agree that would be a very nice way of doing it - it's a shame
RDF is so limited. *However*, I do think some of RDF limitations can
be good, in the way it forces one to think in really straight-forward
data structures. Certainly, for all that touches justifications (which
is essentially what Kurt is trying to achieve here), RDF makes things
really hard... Most provenance/justification RDF vocabularies are, to
say the least, very twisted and hard to understand... I think N3
(which is essentially Prolog with URIs :-) ) provides a much nicer
way, in a RDF world, to express such things, but there are still some
rough edges.
Yes, that's exactly it - I wonder if this approach would be worth generalising.
This approach was mainly driven by the fact RDF collections weren't
very well handled in RDF tools (and very painful to serialise). Let's
hope it might change soon...
>
> The reason I've gone on at such length about this is that it's by no
> means an isolated problem - I started working with the chord ontology
> recently and found the representation of notes and scale degrees problematic
> precisely because it was not a faithful translation of the fairly straightforward
> algebraic data types that one might define for such things, and indeed we
> did define in our original paper on the subject (Harte, Sandler, Abdallah, Gómez,
> 2005; 'Symbolic Representation of Musical Chords: A Proposed Syntax for Text Annotations').
>
Oh really? I wonder if Chris is still on this list (he basically wrote
the whole spec) - I would be curious to know what problems you
encountered in the chord ontology. Is the web service also broken,
then?
Cheers,
y
Kurt J
[snip]
>> :FunkyPL a seq:Sequence;
>> seq:length 2;
>> seq:has_slot {
>> seq:index 1;
>> seq:item :SexMachine
>> };
>> seq:has_slot {
>> seq:index 2;
>> seq:item :GoodFoot
>> }.
>>
>> ... which is almost readable.
>> The justification thing Kurt proposed could be attached to a sub-class
>> of seq:Slot, eg mo:PlaylistSlot, as long as seq:index > 1.
>>
>> Going back to Yves' mention of Tracks and track_number, this
>> suggest that a Track plays the role of a seq:Slot for mo:Signals in the
>> context of the sequence defined by an album.
>
> Yes, that's exactly it - I wonder if this approach would be worth generalising.
> This approach was mainly driven by the fact RDF collections weren't
> very well handled in RDF tools (and very painful to serialise). Let's
> hope it might change soon...
+1 i think you're on to something here and i think it is probably
worth generalizing.
it seems pretty clear to me that the RDF world needs better solutions
for ordered lists and a small sequence ontology would really help my
application.
a SPARQL query to load audio from such a playlist would be not so bad...
SELECT ?track_name ?audio
WHERE {
<http://example.com/my_playlist> seq:has_slot ?slots .
?slots seq:item ?track .
?track dc:title ?track_name;
mo:available_as ?audio .
}
I think that'd be pretty quick in most triple stores but my intuition
on this seems to be always exactly wrong.
Samer - good to hear from you!
-Kurt J
Samer Abdallah
On 27 Jun 2010, at 16:05, Yves Raimond wrote:
> Hello!
Yes - a system with classes Sequence and Slot, and properties length,
index, item, in_sequence and has_slot would just about cover it I think,
for finite or infinite sequences of any type of thing. Some syntactic sugar
for finite sequences in N3 would make lists quite manageable. The
Sequence and Slot classes could be subclassed freely to restrict the
type of items or add new properties such as Kurt's 'justification'.
>
>>
>> The reason I've gone on at such length about this is that it's by no
>> means an isolated problem - I started working with the chord ontology
>> recently and found the representation of notes and scale degrees problematic
>> precisely because it was not a faithful translation of the fairly straightforward
>> algebraic data types that one might define for such things, and indeed we
>> did define in our original paper on the subject (Harte, Sandler, Abdallah, Gómez,
>> 2005; 'Symbolic Representation of Musical Chords: A Proposed Syntax for Text Annotations').
>>
>
> Oh really? I wonder if Chris is still on this list (he basically wrote
> the whole spec) - I would be curious to know what problems you
> encountered in the chord ontology. Is the web service also broken,
> then?
>
Well, it's not broken really, it's just that it depends on failure
to decide if a given note has a sharp/flat modifier or not. Eg, we decide that
some note N is 'C natural' if we *can* prove that
rdf(N, chord:natural, chord:'note/C')
and we *can't* prove that
rdf(N, chord:modifier, X)
for any X. Thus, we rely on the failure of rdf(N, chord:modifier, X) to conclude
that N is 'C natural' rather than 'C sharp' or 'C flat'. In an open world, this results
in non-monotonic reasoning - if the triple rdf(N, chord:modifier, chord:sharp)
eventually shows up from somewhere, ie we *add* information, we must
*change* our earlier conclusion. This representation of notes is not the same
as the original algebraic type, which we could express in several ways:
note ---> natural(nominal) ; sharp(note) ; flat(note) .
nominal ---> a ; b ; c ; d ; e ; f ; g.
or,
note ---> natural(nominal) ; modified( modifier, note).
modifier ---> sharp ; flat.
nominal ---> a ; b ; c ; d ; e ; f ; g.
or, without recursion but limited enharmonics,
note ---> modified( nominal, modifier).
modifier ---> double_flat ; flat ; natural ; sharp ; double_sharp.
nominal ---> a ; b ; c ; d ; e ; f ; g.
The reason for the non-monoticity of the chord ontology representation is
that it doesn't adequately distinguish between the different note constructors
natural/1, sharp/1 and flat/1, or natural/1 and modified/2. We are thus left to conclude which
constructor is implied based on the *lack* of certain triples. In fact, my last
example above, having only one constructor (=class) with two arguments(=properties),
is the closest to the current chord ontology, suggesting that it could be
fixed by adding a new individual 'chord:natural' of class 'chord:Modifier'.
This would be the simplest thing, but it wouldn't capture the fact that a double_flat
is the same as two flats - it wouldn't model the fact that the sharps and flats are
isomorphic with the integers -2 to 2. So you may as well replace the modifier with
an integer and be done. Personally, I prefer the recursive formulation in the
first two, but in RDF it might well prove simpler to go with:
note ---> modified( nominal, integer).
nominal ---> a ; b ; c ; d ; e ; f ; g.
Samer.