2.1 branch merged in trunk
Yves Raimond
Just a quick note to let you know that I just merged the 2.1 branch
Zazi has been working on in trunk, with a couple of very minor
changes:
http://wiki.musicontology.com/index.php/MOProposal21
I will quickly go through the todo list to see if everything is OK,
and hopefully put out a new release soon.
Cheers,
y
Alexandre Passant
On 28 Nov 2010, at 13:25, Yves Raimond wrote:
> Hello!
>
> Just a quick note to let you know that I just merged the 2.1 branch
> Zazi has been working on in trunk, with a couple of very minor
> changes:
>
> http://wiki.musicontology.com/index.php/MOProposal21
Will it include the proposed changes re. domain of instrument / label ?
Thanks,
Alex.
>
> I will quickly go through the todo list to see if everything is OK,
> and hopefully put out a new release soon.
>
> Cheers,
> y
>
> --
> 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.
>
--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .
Yves Raimond
<alexandr...@deri.org> wrote:
> Hi,
>
> On 28 Nov 2010, at 13:25, Yves Raimond wrote:
>
>> Hello!
>>
>> Just a quick note to let you know that I just merged the 2.1 branch
>> Zazi has been working on in trunk, with a couple of very minor
>> changes:
>>
>> http://wiki.musicontology.com/index.php/MOProposal21
>
> Will it include the proposed changes re. domain of instrument / label ?
>
> http://groups.google.com/group/music-ontology-specification-group/browse_thread/thread/6ec4bb8ac89bfe9c#
Yes - it's in there already. I did make a change to Zazi's proposal
though: the mo:primary_instrument includes agent in its domain now but
the mo:instrument one was left unmodified - is that OK?
Cheers,
y
Alexandre Passant
On 28 Nov 2010, at 14:00, Yves Raimond wrote:
> On Sun, Nov 28, 2010 at 1:48 PM, Alexandre Passant
> <alexandr...@deri.org> wrote:
>> Hi,
>>
>> On 28 Nov 2010, at 13:25, Yves Raimond wrote:
>>
>>> Hello!
>>>
>>> Just a quick note to let you know that I just merged the 2.1 branch
>>> Zazi has been working on in trunk, with a couple of very minor
>>> changes:
>>>
>>> http://wiki.musicontology.com/index.php/MOProposal21
>>
>> Will it include the proposed changes re. domain of instrument / label ?
>>
>> http://groups.google.com/group/music-ontology-specification-group/browse_thread/thread/6ec4bb8ac89bfe9c#
>
> Yes - it's in there already. I did make a change to Zazi's proposal
> though: the mo:primary_instrument includes agent in its domain now but
> the mo:instrument one was left unmodified - is that OK?
It be good to also have the range of instrument changed, unless it conflicts with other modeling attributes.
Especially if we go into precise instrument types / models.
E.g.
:x mo:primary_instrument :Guitar ;
mo:instrument :Gibson_SG_1977 ;
mo:instrument :Gibson_SG_1978 .
Alex.
Yves Raimond
<alexandr...@deri.org> wrote:
>
> On 28 Nov 2010, at 14:00, Yves Raimond wrote:
>
>> On Sun, Nov 28, 2010 at 1:48 PM, Alexandre Passant
>> <alexandr...@deri.org> wrote:
>>> Hi,
>>>
>>> On 28 Nov 2010, at 13:25, Yves Raimond wrote:
>>>
>>>> Hello!
>>>>
>>>> Just a quick note to let you know that I just merged the 2.1 branch
>>>> Zazi has been working on in trunk, with a couple of very minor
>>>> changes:
>>>>
>>>> http://wiki.musicontology.com/index.php/MOProposal21
>>>
>>> Will it include the proposed changes re. domain of instrument / label ?
>>>
>>> http://groups.google.com/group/music-ontology-specification-group/browse_thread/thread/6ec4bb8ac89bfe9c#
>>
>> Yes - it's in there already. I did make a change to Zazi's proposal
>> though: the mo:primary_instrument includes agent in its domain now but
>> the mo:instrument one was left unmodified - is that OK?
>
> It be good to also have the range of instrument changed, unless it conflicts with other modeling attributes.
>
> Especially if we go into precise instrument types / models.
> E.g.
> :x mo:primary_instrument :Guitar ;
> mo:instrument :Gibson_SG_1977 ;
> mo:instrument :Gibson_SG_1978 .
Hmm. In the sense of 'owns' then? Perhaps it should belong to a
separate vocab (there must be something out there defining a 'owning'
predicate? perhaps good relations?)
Cheers,
y
Alexandre Passant
hmmm ... I won't directly use own here, unless we add things like #num of the particular guitar.
That said, if that's too complex / conflict, I can leave with primary_instrument and use only that one when modelling relation between and artist and its instruments.
Alex.
Bob Ferris
re. the mo:interpreter property:
AFAIK, I added this property during my ID3 tag to Music Ontology
mapping[1] to have a relation for the case, where I can extract a
related person that interpreted/remixed etc. somehow the described music
track, but I do not really know the exact relation, e.g. remixer
(mo:remixer) or sampler (mo:sampler).
re. the instruments relation:
Am I right: you would use in general a kind of "own relation" (hopefully
from another ontology) to related a music instrument to a person and
mo:primary_instrument to related the primary instrument of an artist to
him/her? And mo:instrument should only be used for temporal relations of
used instruments in performances?
Maybe we should then rename mo:instrument to mo:used_instrument, which
might intent a clearer usage.
An opportunity to express that some can play a certain instrument is to
apply the Cognitive Characteristics Ontology e.g.,
ex:APerson
a foaf:Person ;
foaf:name "John White" ;
cco:skill <http://dbpedia.org/resource/Piano> ;
cco:habit [
a cco:CognitiveCharacteristic ;
cco:topic <http://dbpedia.org/resource/Piano> ;
cco:characteristic cco:skill ;
wo:weight [
a wo:Weight ;
wo:weight_value 6.0 ;
wo:scale ex:AScale
] ;
cco:activity
<http://sw.opencyc.org/concept/Mx4rvVjUJ5wpEbGdrcN5Y29ycA>
] .
Which says in its shortcut relation that "John White has some skills in
piano", which makes probably more sense its reified form that "John
White can play the piano quite good" (cf. [2]).
However, this description doesn't say anything about that John White has
an piano.
Cheers,
Bob
[1] http://smiy.svn.sourceforge.net/viewvc/smiy/pmkb-aperture-extractor/
(untested, because my working machine is broken since the last the last
commitment there :\)
[2]
http://purl.org/ontology/cco/cognitivecharacteristics.html#sec-UMIRL-example
Yves Raimond
I've now went through the ToDo list, cleaned it, and finished the last
couple of items - there are now just two outstanding items, which I
think I'll leave for now, as it may need some more discussions:
http://wiki.musicontology.com/index.php/Todo_list
http://wiki.musicontology.com/index.php/MOProposal21#MO_Proposal_2.1
The up to date ontology is available from there:
http://motools.svn.sourceforge.net/viewvc/motools/mo/rdf/musicontology.n3
Added to the things we discussed before, I added three new properties,
that were requested by Alexandre earlier:
* activity_start and activity_end (from an artist to an xsd:date)
* origin (from an artist to a geo:SpatialThing)
I'll put out a new release if all is fine.
Cheers,
y
Yves Raimond
Thanks a lot to you Zazi! I couldn't have done it so quickly without
the amazing work you did in the 2.1 branch!!
>
> re. the mo:interpreter property:
>
> AFAIK, I added this property during my ID3 tag to Music Ontology mapping[1]
> to have a relation for the case, where I can extract a related person that
> interpreted/remixed etc. somehow the described music track, but I do not
> really know the exact relation, e.g. remixer (mo:remixer) or sampler
> (mo:sampler).
Oh OK - that makes sense. It certainly a lot better than what we had
before anyway, so I am happy to leave it in for now.
>
> re. the instruments relation:
>
> Am I right: you would use in general a kind of "own relation" (hopefully
> from another ontology) to related a music instrument to a person and
> mo:primary_instrument to related the primary instrument of an artist to
> him/her? And mo:instrument should only be used for temporal relations of
> used instruments in performances?
Yes, I was thinking that would be the case.
>
> Maybe we should then rename mo:instrument to mo:used_instrument, which might
> intent a clearer usage.
Yes - some of those performance properties have very generic labels,
but I think we can live with that for now? (Or maybe just changing the
rdfs:label?)
>
> An opportunity to express that some can play a certain instrument is to
> apply the Cognitive Characteristics Ontology e.g.,
>
> ex:APerson
> a foaf:Person ;
> foaf:name "John White" ;
> cco:skill <http://dbpedia.org/resource/Piano> ;
> cco:habit [
> a cco:CognitiveCharacteristic ;
> cco:topic <http://dbpedia.org/resource/Piano> ;
> cco:characteristic cco:skill ;
> wo:weight [
> a wo:Weight ;
> wo:weight_value 6.0 ;
> wo:scale ex:AScale
> ] ;
> cco:activity <http://sw.opencyc.org/concept/Mx4rvVjUJ5wpEbGdrcN5Y29ycA>
> ] .
>
> Which says in its shortcut relation that "John White has some skills in
> piano", which makes probably more sense its reified form that "John White
> can play the piano quite good" (cf. [2]).
> However, this description doesn't say anything about that John White has an
> piano.
OK - after taking a quick look at:
http://www.heppnetz.de/ontologies/goodrelations/goodrelations-UML.png
It looks like there is indeed a gr:owns property - but using it on an
artist would mean it is a 'business entity' - which I am sure many
artists would disagree with :-)
Cheers,
y
>
> Cheers,
>
>
> Bob
>
>
> [1] http://smiy.svn.sourceforge.net/viewvc/smiy/pmkb-aperture-extractor/
> (untested, because my working machine is broken since the last the last
> commitment there :\)
> [2]
> http://purl.org/ontology/cco/cognitivecharacteristics.html#sec-UMIRL-example
>
> Am 28.11.2010 14:25, schrieb Yves Raimond:
>>
>> Hello!
>>
>> Just a quick note to let you know that I just merged the 2.1 branch
>> Zazi has been working on in trunk, with a couple of very minor
>> changes:
>>
>> http://wiki.musicontology.com/index.php/MOProposal21
>>
>> I will quickly go through the todo list to see if everything is OK,
>> and hopefully put out a new release soon.
>>
>> Cheers,
>> y
>>
>
Yves Raimond
And here it is:
A couple of non-modelling things I think would be great for the next release:
* Streamline the publishing process - for historic reason, it is a bit
tedious - HTML docs live on dbtune, and the rest lives on sourceforge,
with sourceforge handling the (broken, as based on mod_rewrite) conneg
bit. Everything should be on one server - possibly sourceforge as
everything is static and anyone with a sourceforge account andaccess
to the motools project can publish a new revision.
* Clean the CSS and make the spec pretty
* Clean the specification - there's too much not very useful text in there
* A JS-based MO-m-atic for generating MO RDF for the most common
cases: tracks/artists/albums, digital availability, performances,
works, etc., on the spec page itself (better than a long list of
example, maybe?)
Cheers,
y
Bob Ferris
some minor issues:
1. I guess, you probably know already my point of view re. the domain of
mo:label (the mo:ReleaseEvent/mo:Release discussion, see [1]). I'm not
really happen when we would move it to mo:Release ;)
2. Maybe we should note it again: we are now also able to associate
media types on the manifestation level via mo:media_type [2]. One can
use for instance some predefined ones from [3].
Cheers,
Bob
[1]
http://groups.google.com/group/music-ontology-specification-group/msg/63a32902a9a5cea6
[2] http://www.musicontology.com/#term_media_type
[3] http://purl.org/ontology/mt/
Kingsley Idehen
> Well done, Yves!
>
> some minor issues:
>
> 1. I guess, you probably know already my point of view re. the domain
> of mo:label (the mo:ReleaseEvent/mo:Release discussion, see [1]). I'm
> not really happen when we would move it to mo:Release ;)
>
> 2. Maybe we should note it again: we are now also able to associate
> media types on the manifestation level via mo:media_type [2]. One can
> use for instance some predefined ones from [3].
>
> Cheers,
>
>
> Bob
>
> [1]
> http://groups.google.com/group/music-ontology-specification-group/msg/63a32902a9a5cea6
> [2] http://www.musicontology.com/#term_media_type
> [3] http://purl.org/ontology/mt/
Bob,
Any chance of adding some isDefinedBy triples to the media type ontology
[1] so that we can navigate holistically via Linked Data browsers? On
the Ontology instance data side, foaf:primarytopic or wdrs:describedby
that bring their .rdf descriptor document into scope re.
follow-your-nose navigation.
Examples:
1. http://purl.org/ontology/mt/ -- your media type ontology
2.
http://linkeddata.uriburner.com/describe/?url=http://purl.org/ontology/mt/SVCD
-- not route to the .rdf doc that holds descriptions
3.
http://linkeddata.uriburner.com/about/html/http/smiy.sourceforge.net/mt/rdf/mediatypes.rdf
- empty until there are triples the pull in the .rdf doc
4.
http://linkeddata.uriburner.com/ode/?uri%5B%5D=http%3A%2F%2Flinkeddata.uriburner.com%2Fabout%2Fid%2Fentity%2Fhttp%2Fsmiy.sourceforge.net%2Fmt%2Frdf%2Fmediatypes.rdf&
-- this shows content of .rdf doc which is why you see something .
Kingsley
--
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
I can add is-defined-by relations, of course. However, I would prefer to
associate the descriptions to their namespace
(http://purl.org/ontology/mt/ - as we do it currently also with
rdfs:isDefinedBy relations in ontology definitions), rather then to the
rdf/xml representation in the .rdf document. Currently, you should also
get a text/turtle representation in a .n3 document (AFAIK), when you
request this MIME type. And hopefully, someday in the future also a RDFa
representation for better human-readability in a normal web browser.
Cheers,
Bob
Kingsley Idehen
> Hi Kingsley,
>
> I can add is-defined-by relations, of course. However, I would prefer
> to associate the descriptions to their namespace
> (http://purl.org/ontology/mt/ - as we do it currently also with
> rdfs:isDefinedBy relations in ontology definitions), rather then to
> the rdf/xml representation in the .rdf document. Currently, you should
> also get a text/turtle representation in a .n3 document (AFAIK), when
> you request this MIME type. And hopefully, someday in the future also
> a RDFa representation for better human-readability in a normal web
> browser.
Anyway, looking better as per:
http://linkeddata.uriburner.com/describe/?url=http%3A%2F%2Ffoaf.me%2Fzazi%23me
.
I can follow links to holistic start points re. your ontologies :-)
Kingsley
Yves Raimond
> some minor issues:
>
> 1. I guess, you probably know already my point of view re. the domain of
> mo:label (the mo:ReleaseEvent/mo:Release discussion, see [1]). I'm not
> really happen when we would move it to mo:Release ;)
Yes, I sort of got that :) There was no strong consensus in that
thread, so I took the decision that most people said they were happy
with. Hopefully that's ok...
>
> 2. Maybe we should note it again: we are now also able to associate media
> types on the manifestation level via mo:media_type [2]. One can use for
> instance some predefined ones from [3].
Cool!
Cheers,
y
Bob Ferris
> Hello!
>
>> some minor issues:
>>
>> 1. I guess, you probably know already my point of view re. the domain of
>> mo:label (the mo:ReleaseEvent/mo:Release discussion, see [1]). I'm not
>> really happen when we would move it to mo:Release ;)
>
> Yes, I sort of got that :) There was no strong consensus in that
> thread, so I took the decision that most people said they were happy
> with. Hopefully that's ok...
What about broaden the domain to mo:Release and mo:ReleaseEvent? :)
Cheers,
Bob
PS: which relations are now left for mo:ReleaseEvent instances? - time
and place. however, are there any more?
Bob Ferris
Am 29.11.2010 21:22, schrieb Kingsley Idehen:
> On 11/29/10 2:34 PM, Bob Ferris wrote:
>> Well done, Yves!
>>
>> some minor issues:
>>
>> 1. I guess, you probably know already my point of view re. the domain
>> of mo:label (the mo:ReleaseEvent/mo:Release discussion, see [1]). I'm
>> not really happen when we would move it to mo:Release ;)
>>
>> 2. Maybe we should note it again: we are now also able to associate
>> media types on the manifestation level via mo:media_type [2]. One can
>> use for instance some predefined ones from [3].
>>
>> Cheers,
>>
>>
>> Bob
>>
>> [1]
>> http://groups.google.com/group/music-ontology-specification-group/msg/63a32902a9a5cea6
>>
>> [2] http://www.musicontology.com/#term_media_type
>> [3] http://purl.org/ontology/mt/
>
> Bob,
>
> Any chance of adding some isDefinedBy triples to the media type ontology
> [1] so that we can navigate holistically via Linked Data browsers? On
> the Ontology instance data side, foaf:primarytopic or wdrs:describedby
> that bring their .rdf descriptor document into scope re.
> follow-your-nose navigation.
by fluke I view [1] in the Tabulator browser and by looking at this
representation I determined that probably already everything is fine. I
defined this namespace as SKOS concept scheme and every class is part of
that scheme and linked back with the property skos:inScheme. I guess
this might be enough, or?
Cheers,
Bob