This is my propositions for the enxt round of revisions. I know that Yves will make some more suggestion over the weekend, but I think that most of what we talked about in the last threads (except for Instruments and Genres, Florent is working on that atm).
Also, I added properties that restrict event:hasFactor and event:isAgentIn as suggested by Ivan. I know that Yves should also make some more propositions here.
So, the new revision should be released sometime next week.
Take care,
Fred
============================================ Creation of mo:composed ============================================
Constraining event:isAgentIn (more explicit, so more easy to understand)
I would add mo:Recording in the domain of mo:conductor and mo:Recording in the range of mo:conducted. The idea is that a music artist can conduct Recording too (and not only performance).
> ============================================ > Creation of mo:composed > ============================================
> Constraining event:isAgentIn (more explicit, so more easy to understand)
I am not sure we really need the property *and* the inverse property (as it allows two ways of expressing the same thing, and if we don't have any reasoning, this may cause some troubles). I suggest that we just restrict hasAgent, and drop isAgentIn out. What do you think?
> I would add mo:Recording in the domain of mo:conductor and mo:Recording in > the range of mo:conducted. > The idea is that a music artist can conduct Recording too (and not only > performance).
Mmmm... for this, I would suggest the use of mo:engineer (an engineer will "conduct" the recording).
> ============================================ > Adding timeline:endsAtDateTime to the MO documentation > ============================================
> Where it is not there? (we have timeline:startsAtDateTime after all ;) )
Well, still the same thing: for the sake of "one way of expressing one thing", I dropped it, to force users to express a time interval using its start time and its duration. This was just an arbitrary choice, though:-)
> Constraining event:isAgentIn (more explicit, so more easy to understand)
I don't understand why the range is a MusicalManifestation here. and why it is a subproperty of isAgentIn (isAgentIn relates an Agent to an Event, and no musical manifestations are events). I thought that in the last thread launched by Florent, we agreed that these properties should concern Signal. Thus, I would suggest djmixed domain Agent djmixed range Signal
Not sure about the name (though my english could be too bad:-) ). I was thinking Venue was more a place to see a gig, so more linked to a geo:Feature. Is there an english word for the french "Spectacle"?
sorry I was not really available last week, so I just saw your discussions from far away (spending my time with a stupid thing: my laptop has been changed, which is a good thing, but then I had to spend two days or more to reinstall all applications, profiles, etc, etc. This is really an awful aspect of Windows:-(
Anyway... just a few comments below
On Mar 9, 4:54 pm, Frederick Giasson <f...@fgiasson.com> wrote:
> Hi All,
> This is my propositions for the enxt round of revisions. I know that Yves will > make some more suggestion over the weekend, but I think that most of what we > talked about in the last threads (except for Instruments and Genres, Florent is > working on that atm).
> I would add mo:Recording in the domain of mo:conductor and mo:Recording in > the range of mo:conducted. > The idea is that a music artist can conduct Recording too (and not only > performance).
I am not sure I understand that. If we separate Recording and Performance as we do, then how would a conductor conduct a recording? You may have another (larger) view of a conductor, I am afraid...
> > Constraining event:isAgentIn (more explicit, so more easy to understand)
> I am not sure we really need the property *and* the inverse property > (as it allows two ways of expressing the same thing, and if we don't > have any reasoning, this may cause some troubles). I suggest that we > just restrict hasAgent, and drop isAgentIn out. What do you think?
You mean it would complicate queries, right? Which is true, but we should still see whether the user friendliness is worth the extra trouble... Maybe we should mark that as 'in danger' and leave it in for now...
There are number of inverse relationships in the ontology as far as I remember. So either we have to remove _all_, or, well, ....
[snip]
> > I would add mo:Recording in the domain of mo:conductor and mo:Recording in > > the range of mo:conducted. > > The idea is that a music artist can conduct Recording too (and not only > > performance).
> Mmmm... for this, I would suggest the use of mo:engineer (an engineer > will "conduct" the recording).
Ah! I should have read this before answering Fred's mail directly. Indeed, I would separate conductor and and the engineer. These are very very different!
> > ============================================ > > Adding timeline:endsAtDateTime to the MO documentation > > ============================================
> > Where it is not there? (we have timeline:startsAtDateTime after all ;) )
> Well, still the same thing: for the sake of "one way of expressing one > thing", I dropped it, to force users to express a time interval using > its start time and its duration. This was just an arbitrary choice, > though:-)
> Not sure about the name (though my english could be too bad:-) ). I > was thinking Venue was more a place to see a gig, so more linked to a > geo:Feature. Is there an english word for the french "Spectacle"?
In my small dictionary 'venue: the scene of any event or action, especially the place of a meeting'. I am not sure what Fred's intention was with this Class. Is there a difference between this and the SpatialThing that was already used somewhere else?
Ivan
P.S. Yves, actually, I am in London from Mo to We, but on a conference...
> sorry I was not really available last week, so I just saw your > discussions from far away (spending my time with a stupid thing: my > laptop has been changed, which is a good thing, but then I had to > spend two days or more to reinstall all applications, profiles, etc, > etc. This is really an awful aspect of Windows:-(
Doh! This is always a terrible moment in the life of a developer :)
It is awesome to see how much time we can lose setting up a new computer :)
Check the instances we already created (album, interview, etc). There are two mores: live and ep... they will help me to describe all relations comming from Musibrainz.
All in all, they are just instances, so you take it or not :)
> > I am not sure we really need the property *and* the inverse property > > (as it allows two ways of expressing the same thing, and if we don't > > have any reasoning, this may cause some troubles). I suggest that we > > just restrict hasAgent, and drop isAgentIn out. What do you think?
> You mean it would complicate queries, right? Which is true, but we > should still see whether the user friendliness is worth the extra > trouble... Maybe we should mark that as 'in danger' and leave it in > for now...
> There are number of inverse relationships in the ontology as far as I > remember. So either we have to remove _all_, or, well, ....
Yeah exactly. At first, I done that the same way a SIOC does. However Yves is right to say that we should try to have only one way to say something.
The possible issue that can arise is loosing some friendliness in the process. Intuitively, someone will say:
- I have the reference of an Artist - Give me the name of the tracks he composed.
and not
- I have the reference of an Artist - Give me the name of the tracks *that have been composed by this artist*
Personally I think that #1 is much more intuitive. However, Yves is right because in the future, one could only use mo:composed, another one only dc:creator, and another one both.
In such a case, a system using that data will have to check for both references to make sure that the link exists or doesn't.
> > Not sure about the name (though my english could be too bad:-) ). I > > was thinking Venue was more a place to see a gig, so more linked to a > > geo:Feature. Is there an english word for the french "Spectacle"?
> In my small dictionary 'venue: the scene of any event or action, > especially the place of a meeting'. I am not sure what Fred's > intention was with this Class. Is there a difference between this and > the SpatialThing that was already used somewhere else?
I was thinking about describing a musical show or a festival, or any gathering related to music.
> I am not sure we really need the property *and* the inverse property > (as it allows two ways of expressing the same thing, and if we don't > have any reasoning, this may cause some troubles). I suggest that we > just restrict hasAgent, and drop isAgentIn out. What do you think?
Considering your obsession for the "only-one-way" rule, I totally agree :)
> > ============================================ > > Adding timeline:endsAtDateTime to the MO documentation > > ============================================
> > Where it is not there? (we have timeline:startsAtDateTime after all ;) )
> Well, still the same thing: for the sake of "one way of expressing one > thing", I dropped it, to force users to express a time interval using > its start time and its duration. This was just an arbitrary choice, > though:-)
Well, but as you can see, I have been duped by that rul, I was thinking that something was missing :)
It is where Ivan was talking about "friendliness".
> > Constraining event:isAgentIn (more explicit, so more easy to understand)
> I don't understand why the range is a MusicalManifestation here. and > why it is a subproperty of isAgentIn (isAgentIn relates an Agent to an > Event, and no musical manifestations are events). > I thought that in the last thread launched by Florent, we agreed that > these properties should concern Signal. > Thus, I would suggest > djmixed domain Agent > djmixed range Signal
> Check the instances we already created (album, interview, etc). There are two > mores: live and ep... they will help me to describe all relations comming from > Musibrainz.
> All in all, they are just instances, so you take it or not :)
Fred, I simply do not know what 'ep' stands for!:-) (I understand 'live':-)
> > > I am not sure we really need the property *and* the inverse property > > > (as it allows two ways of expressing the same thing, and if we don't > > > have any reasoning, this may cause some troubles). I suggest that we > > > just restrict hasAgent, and drop isAgentIn out. What do you think?
> > You mean it would complicate queries, right? Which is true, but we > > should still see whether the user friendliness is worth the extra > > trouble... Maybe we should mark that as 'in danger' and leave it in > > for now...
> > There are number of inverse relationships in the ontology as far as I > > remember. So either we have to remove _all_, or, well, ....
> Yeah exactly. At first, I done that the same way a SIOC does. However Yves is > right to say that we should try to have only one way to say something.
> The possible issue that can arise is loosing some friendliness in the process. > Intuitively, someone will say:
> - I have the reference of an Artist
You mean a composer:-)
> - Give me the name of the tracks he composed.
> and not
> - I have the reference of an Artist > - Give me the name of the tracks *that have been composed by this artist*
> Personally I think that #1 is much more intuitive. However, Yves is right > because in the future, one could only use mo:composed, another one only > dc:creator, and another one both.
My point is: how do I know which one is more intuitive? I am not 100% sure of your intuition. If somebody comes from a linguistic background that makes use of passive form much much more than English or French, like German, for example, then #2 might be just as intuitive than #1 for that person! That is why I am a little bit weary of making this decision.
We have to consider the audience for that ontology. When making an ontology for, say, the medical domain, the users of that ontology will be highly trained professionals, who will accept a certain way of expressing themselves when putting their facts into this ontology framework. The users of this ontology are, however, laypersons who may not want to understand too much of these niceties and want their work done. This is different, and we may want to abandon a certain level of purity for a better acceptance (of course, you might say that laypersons should interact with this ontology via a clever user interface, in which case the issue becomes moot. But we are not yet there... sigh...)
> My point is: how do I know which one is more intuitive? I am not 100% > sure of your intuition. If somebody comes from a linguistic background > that makes use of passive form much much more than English or French, > like German, for example, then #2 might be just as intuitive than #1 > for that person! That is why I am a little bit weary of making this > decision.
I naturally agree with this opinion/fact.
> We have to consider the audience for that ontology. When making an > ontology for, say, the medical domain, the users of that ontology will > be highly trained professionals, who will accept a certain way of > expressing themselves when putting their facts into this ontology > framework. The users of this ontology are, however, laypersons who may > not want to understand too much of these niceties and want their work > done. This is different, and we may want to abandon a certain level of > purity for a better acceptance (of course, you might say that > laypersons should interact with this ontology via a clever user > interface, in which case the issue becomes moot. But we are not yet > there... sigh...)
In that case, we have to make a decision vis-a-vis this tradeoff.
1- Restricting the ontology only one way of expression
2- Creating inverse properties (composed;composer, etc.) into the ontology (like SIOC with parent_of;has_parent etc.).
In a case or another, we have to make the ontology consistant with the choice we will take here for the next revision.
Personally I think I prefer #2 for Ivan's argumentation and because it was my first minding.
Also, I don't think it is that terrible to have two ways to express something.
One can use both to describe the relationship between two resources. If a system want only to use one way or the other, then it only has to use some type of inference if available on its system, or to fix its triple store accordingly (adding/removing triples that fit some criterias).
So, considering that developers has what they need to manipulate the data, I think it would be important to leave this burden to them, and to simplify the ontology for users that can have more less knowledge than developers that will use the data generated by the ontology.
> > My point is: how do I know which one is more intuitive? I am not > 100% > > sure of your intuition. If somebody comes from a linguistic > background > > that makes use of passive form much much more than English or > French, > > like German, for example, then #2 might be just as intuitive than #1 > > for that person! That is why I am a little bit weary of making this > > decision.
> I naturally agree with this opinion/fact.
> > We have to consider the audience for that ontology. When making an > > ontology for, say, the medical domain, the users of that ontology > will > > be highly trained professionals, who will accept a certain way of > > expressing themselves when putting their facts into this ontology > > framework. The users of this ontology are, however, laypersons who > may > > not want to understand too much of these niceties and want their > work > > done. This is different, and we may want to abandon a certain level > of > > purity for a better acceptance (of course, you might say that > > laypersons should interact with this ontology via a clever user > > interface, in which case the issue becomes moot. But we are not yet > > there... sigh...)
> In that case, we have to make a decision vis-a-vis this tradeoff.
> 1- Restricting the ontology only one way of expression
> 2- Creating inverse properties (composed;composer, etc.) into the > ontology (like SIOC with parent_of;has_parent etc.).
> In a case or another, we have to make the ontology consistant with > the choice we will take here for the next revision.
> Personally I think I prefer #2 for Ivan's argumentation and because > it was my first minding.
> Also, I don't think it is that terrible to have two ways to express > something.
> One can use both to describe the relationship between two resources. > If a system want only to use one way or the other, then it only has > to use some type of inference if available on its system, or to fix > its triple store accordingly (adding/removing triples that fit some > criterias).
> So, considering that developers has what they need to manipulate the > data, I think it would be important to leave this burden to them, and > to simplify the ontology for users that can have more less knowledge > than developers that will use the data generated by the ontology.
> What do you think?
I think we are in wild agreement:-)
Ivan
P.S. I was wondering, based on your name: are you actually German?
This mailing list is definitely trusted by french speaking people:-)
To answer the issue of inverse properties, I definitely think it is really dangerous. I don't really want, when querying data based on MO, to do an UNION for each possibility, if the SPARQL end point has no (or a too restrictive) reasoning support.
I don't think it is really much more complicated to only allow one property to express one thing. I even think it is really much clearer for the user ("oh, there's two properties to express the same thing, which one should I use?").
> This mailing list is definitely trusted by french speaking people:-)
> To answer the issue of inverse properties, I definitely think it is > really dangerous. I don't really want, when querying data based on MO, > to do an UNION for each possibility, if the SPARQL end point has no > (or a too restrictive) reasoning support.
> I don't think it is really much more complicated to only allow one > property to express one thing. I even think it is really much clearer > for the user ("oh, there's two properties to express the same thing, > which one should I use?").
Well, I understand you fears here Yves, but there is a decision to take, and there is no perfect solution for our problem.
We have the choice:
1- Only one way to express things and making the ontology less user friendly.
2- Creating inverse properties into the ontology, having 2 ways to express things, and leaving the burden of playing with that data to the developers.
Personally I think I would take the risk of #2 since we try to reach user adoption and friendlyness. Also, we can always write a best practice document to explain the best way to write MO documents.
Also, I am playing with thes UNION patterns for a full of use case with Zitgist since some months, and really, there is no other solution. It is the developer's burden to create its system as effective as possible with the data available. Inference, data manipulation, or anything else: it is its job to make its system view the data.
Best practice for the semantic web? Probably not, but there is solution, and I think we should make the ontology as easy to use as possible.
It is only my opinion, but we should take a decision concerning this issue asap.
What I could suggest is to put a "unstable" tag on one of the relation, and " stable tag" on the other. That way, people will know that there is a better way to express things than the other. That way, eventually, we could drop these inverse properties if we find that they are really armful for the ontology's development.
> What I could suggest is to put a "unstable" tag on one of the relation, and " > stable tag" on the other. That way, people will know that there is a better way > to express things than the other. That way, eventually, we could drop these > inverse properties if we find that they are really armful for the ontology's > development.
Well, that seems like a fair compromise:-) It is ok for me.
> > What I could suggest is to put a "unstable" tag on one of the relation, and > " > > stable tag" on the other. That way, people will know that there is a better > way > > to express things than the other. That way, eventually, we could drop > these > > inverse properties if we find that they are really armful for the > ontology's > > development.
> Well, that seems like a fair compromise:-) It is ok for me.
Okay good, so we should go in that way :)
Anyone else: please tell me if you have any objections before the end of the day, otherwise I will create the revision/RDF dump of MBZ according to that decision in the next days.
