Proposed additions to MO

[Alexandre Passant]

Hi all,

I have 2 proposal for additions in MO

** Modelling activity

In a previous thread, we discussed activity_start / end to model
activity timeframe of a band - that was eventually added to the spec.
While it is useful in many cases, it becomes complex for artists that
have a segmented lifetime.

For instance, http://en.wikipedia.org/wiki/The_Specials
Using the previous properties, the model will be
ex:The_Specials
mo:activity_start "1977" ;
mo:activity_end "1984" ;
mo:activity_start "1996" ;
mo:activity_end "2001" ;
mo:activity_start "2008" ;

This makes SPARQL queries more complex and time consuming when running
activity-based queries, such as finding bands active in 1990 (filter +
negation)

Creating a mo:activity property and a mo:Activity class (subclass of
ev:Event) to model artist activities period would solve this. The
previous example would be:

ex:The_Specials
mo:activity [
a mo:Activity ;
ev:time [
tl:start "1977" ;
tl:end "1984" ;
]
]

etc. and SPARQL queries could be more simpler

** Membership

The current mo:Membership class has a mo:group property to link a
membership to the group, but it will be useful to have mo:artist to
link a Membership to an artist.
E.g

(from the example)
ex:george_harrison
mo:membership [
a mo:Membership ;
mo:group ex:the_beatles .
]

but also:

ex:the_beatles
mo:membership [
a mo:Membership ;
mo:artist ex:georges_harrison .
]

This will simplify things for serialisation such as JSON-LD where
objects can be chained, and the order band -> membership -> member
could also be exposed (similarly to the current member -> membership -
> band)

Any opinions ?

Thanks

Alex.

[Bob Ferris]

Hi Alex,

Yeah, this modelling seems more promising. It is especially in addition
to mo:Membership. Maybe we can outsource this property to a more general
artists ontology (or something appropriated existing one).

> ** Membership
>
> The current mo:Membership class has a mo:group property to link a
> membership to the group, but it will be useful to have mo:artist to
> link a Membership to an artist.
> E.g
>
> (from the example)
> ex:george_harrison
> mo:membership [
> a mo:Membership ;
> mo:group ex:the_beatles .
> ]
>
> but also:
>
> ex:the_beatles
> mo:membership [
> a mo:Membership ;
> mo:artist ex:georges_harrison .
> ]
>
> This will simplify things for serialisation such as JSON-LD where
> objects can be chained, and the order band -> membership -> member
> could also be exposed (similarly to the current member -> membership -
>> band)

I object a bit these changes to the mo:Membership class, because it
would make its sense a bit more ambiguous. Especially since one can
specify properties like mo:primary_instrument to a musician in a band.
If you like, you can go with the shorter form by utilising something
like foaf:member.

Cheers,

Bob

[Alexandre Passant]

Hi

I won't go for a separate model, I think that fits well with the scope of MO

>
>> ** Membership
>>
>> The current mo:Membership class has a mo:group property to link a
>> membership to the group, but it will be useful to have mo:artist to
>> link a Membership to an artist.
>> E.g
>>
>> (from the example)
>> ex:george_harrison
>>   mo:membership [
>>     a mo:Membership ;
>>     mo:group ex:the_beatles .
>>   ]
>>
>> but also:
>>
>> ex:the_beatles
>>   mo:membership [
>>     a mo:Membership ;
>>     mo:artist ex:georges_harrison .
>>   ]
>>
>> This will simplify things for serialisation such as JSON-LD where
>> objects can be chained, and the order band ->  membership ->  member
>> could also be exposed (similarly to the current member ->  membership -
>>>
>>> band)
>
> I object a bit these changes to the mo:Membership class, because it would
> make its sense a bit more ambiguous. Especially since one can specify
> properties like mo:primary_instrument to a musician in a band. If you like,
> you can go with the shorter form by utilising something like foaf:member.

Why more ambiguous ?
So far, mo:membership has foaf:Agent as a domain, so it can be already
used to link a group to a membership.
And the use of mo:primary_instrument is not an issue neither, you can
use something like

ex:the_beatles
  mo:membership [
    a mo:Membership ;

    mo:artist ex:georges_harrison ;
mo:primary_instrument ex:guitar .
  ]

The short form is already present in MO, in both direction (member /
member_of), but there is only one way to model the reified version
through mo:Membership

Alex.

>
> Cheers,
>
>
> Bob
>
> --
> 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 - @terraces
Founder, CEO - seevl.net - @seevl
Reinventing Music Discovery

[Bob Ferris]

Hi Alex,

Btw, here is a third variant:

<#membership> a mo:Membership ;
mo:artist ex:georges_harrison ;
mo:group ex:the_beatles ;

mo:primary_instrument ex:guitar .

;)

Cheers,

Bob

[Yves Raimond]

Hello!

That makes perfect sense. +1

>
> ** Membership
>
> The current mo:Membership class has a mo:group property to link a
> membership to the group, but it will be useful to have mo:artist to
> link a Membership to an artist.
> E.g
>
> (from the example)
> ex:george_harrison
>  mo:membership [
>    a mo:Membership ;
>    mo:group ex:the_beatles .
>  ]
>
> but also:
>
> ex:the_beatles
>  mo:membership [
>    a mo:Membership ;
>    mo:artist ex:georges_harrison .
>  ]
>
> This will simplify things for serialisation such as JSON-LD where
> objects can be chained, and the order band -> membership -> member
> could also be exposed (similarly to the current member -> membership -
>> band)

That makes perfect sense too - I wonder why we missed that though!

Can you add that to the TODO list? (we really need to switch MO to
Neologism or something a bit more, hem, agile...)

Cheers,
y

>
> Any opinions ?
>
> Thanks
>
> Alex.
>

[Alexandre Passant]

Done - I've added these to the TODO list.
Regarding the more agile process, would it make sense to put the spec
on github to allow anyone to make a change once it's agreed ?

Neologism would be fine but not sure (in its current stage) that it
can handle some OWL axioms defined in MO.

Alex.

--

[Bob Ferris]

Hi,

On 7/7/2011 3:37 PM, Alexandre Passant wrote:
> Done - I've added these to the TODO list.
> Regarding the more agile process, would it make sense to put the spec
> on github to allow anyone to make a change once it's agreed ?

+1 for GitHub.

Cheers,

Bob

PS: I will push all the SMI ontologies to GitHub as well ASAP ;)

[Yves Raimond]

You're right - we could move it from Sourceforge to Github, and set up
a post push hook to regenerate and publish the spec on the site.

y