From bogus@does.not.exist.com Sun Nov 1 15:14:03 2009 From: bogus@does.not.exist.com () Date: Sun, 01 Nov 2009 23:14:03 -0000 Subject: No subject Message-ID: Vazaar Project Blog [...] vazaar://00000000-0000-0000-0000-000000000000 vazaar://11111111-1111-1111-1111-111111111111 vazaar://22222222-2222-2222-2222-222222222222 Personal Information Manager [...] NEPOMUK - The Social Semantic Desktop /xwiki/bin/view/Main1/ http http://nepomuk.semanticdesktop.org/xwiki/bin/view/Main1/ 200 2009-09-29 14:29:41 text/html 2009-09-29 14:29:41 nepomuk.semanticdesktop.org text nepomuk.semanticdesktop.org vazaar://22222222-2222-2222-2222-222222222222 html semantic desktop [...] I'm not sure if the above code fits with the specifications but it is more or less what I have in mind. Also, I'm very interested to know if I'm using the proper model. Reading the other replies and other websites I've realized that there is a world of applications using semantic web technologies (soprano in KDE, Tracker in GNOME, etc...). One milestone of this program would be to implement a sparql endpoint to share information. I would like to share more ideas. Tags are not the main problem in my project. Topics, Collections and other Things keep me very busy too. But I'll leave them for next mails. Regards, Tom=E1s V=EDrseda 2009/9/25 Leo Sauermann > > Hi, > > as others may be interested in this discussion, I am also including xesam > (=3D the ontology developers list) > > I was a bit slow to answer, sorry. > > Tom=E1s - what are you programming? do you have a url or a blogpost about= your work? > > nao:Tag is for systems that just use NAO/NIE and are fine with no-brainer= solutions. > a nao:Tag has the semantic meaning of : the tag is a string. its unique. > > pimo:Tag is for systems that want to achieve a highlevel integration of A= ddressbooks, Calendars, Websites, etc... into a semantic network. pimo:Tags= are then not only tags, but can be also a pimo:Person - that is, you can u= se a person's name to tag something but - surprise - it is also a person. > now clicking on the person will get more... > a pimo:Tag has the semantic meaning of : the tag is a unique string which= is also a Thing out of the real world which can have more attributes. > > I also documented this here in the FAQ > https://sourceforge.net/apps/trac/oscaf/wiki/PIMO/FAQ#Whatisthedifference= betweennao:Tagandpimo:Tag > > best > Leo > > > > It was Tom=E1s V=EDrseda who said at the right time 12.09.2009 23:50 the = following words: >> >> Hi, >> >> I'm confused about pimo:Tag and nao:Tag classes described in their >> respective ontology. Which is the difference between these two clases? >> I'm reading the ontologies documentation but I can't still figure out >> how they should be used. I'm developing a tagging system in a >> application and I would like to use Nepomuk. >> >> About pimo:Tag description: >> "Tags in the context of PIMO. A marker class for Things that are used >> to categorize documents (or other things). Tags must be a kind of >> Thing and must have a unique label. Documents should not be Tags by >> default." >> >> About nao:Tag description: >> "This class is useful for modelling conventional tagging practices. >> The user can tag resources in conventional ways, automatically >> creating an instance of this tag, which is then related to the >> annotated resource via the nao:hasTag property. For more on tagging as >> annotation see Section 2.3.". I've read this section and the >> explanation is very convincing. >> >> Thanks in advance. >> Kind regards >> >> -- >> Tom=E1s V=EDrseda >> _______________________________________________ >> people mailing list >> people at semanticdesktop.org >> http://lists.semanticdesktop.org/mailman/listinfo/people >> >> > > > -- > _____________________________________________________ > Dr. Leo Sauermann =A0 =A0 =A0 http://www.dfki.de/~sauermann > Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH > Trippstadter Strasse 122 > P.O. Box 2080 =A0 =A0 =A0 =A0 =A0 Fon: =A0 +43 6991 gnowsis > D-67663 Kaiserslautern =A0Fax: =A0 +49 631 20575-102 > Germany =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mail: =A0leo.sauermann at dfki.de > > Geschaeftsfuehrung: > Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > Amtsgericht Kaiserslautern, HRB 2313 > _____________________________________________________ > From leo.sauermann at dfki.de Sun Nov 8 10:28:38 2009 From: leo.sauermann at dfki.de (Leo Sauermann) Date: Sun, 08 Nov 2009 19:28:38 +0100 Subject: [Xesam] oscaf ontologies: new ontology NSO, moved ontologies to individual pages, maintainers - please get sf accounts Message-ID: <4AF70DD6.6010905@dfki.de> Hi xesam/oscaf/people, As a result of the OpenSocialSemanticDesktopWorkshop2009, we created a new ontology http://techbase.kde.org/Projects/Nepomuk/OpenSocialSemanticDesktopWorkshop2009 It is for sharing data and kept very minimal: https://sourceforge.net/apps/trac/oscaf/wiki/NSO I moved all ontologies to individual pages, also listing the maintainers there. Here are the links to all our ontologies: https://sourceforge.net/apps/trac/oscaf/wiki/Ontologies we deleted NASO from subversion, Laura did not commit anything yet, we wait until she has something. Sebastian Tr?g is working to make a script to release ontologies. If we could reuse the java parts here, would be fine, who is working on this? All maintainers: please get Sourceforge accounts so that you can commit to the svn and do tickets. And join the project. Once you did, add your sf account to your own page. For example, Simon Scerri and Mikkel Kamstrup Erlandsen have no accounts yet: https://sourceforge.net/apps/trac/oscaf/wiki/SimonScerri https://sourceforge.net/apps/trac/oscaf/wiki/MikkelKamstrupErlandsen best Leo -- _____________________________________________________ Dr. Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +43 6991 gnowsis D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo.sauermann at dfki.de Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _____________________________________________________ From bob4job at gmail.com Mon Nov 9 07:30:23 2009 From: bob4job at gmail.com (Roberto Guido) Date: Mon, 09 Nov 2009 16:30:23 +0100 Subject: [Xesam] oscaf ontologies: new ontology NSO, moved ontologies to individual pages, maintainers - please get sf accounts In-Reply-To: <4AF70DD6.6010905@dfki.de> References: <4AF70DD6.6010905@dfki.de> Message-ID: <1257780623.3474.146.camel@madtablet> On Sun, 2009-11-08 at 19:28 +0100, Leo Sauermann wrote: > It is for sharing data and kept very minimal: > https://sourceforge.net/apps/trac/oscaf/wiki/NSO > Has this any correlation with this other project about sharing data among applications? http://cordis.europa.eu/ictresults/index.cfm?section=news&tpl=article&BrowsingType=Features&ID=90977 No explicit links between the two efforts emerges, this is just a personal intuition due the common target (an ontology to share data between applications) and similar involved resources. -- Roberto -MadBob- Guido http://claimid.com/madbob From trueg at kde.org Tue Nov 10 01:47:03 2009 From: trueg at kde.org (Sebastian =?iso-8859-1?q?Tr=FCg?=) Date: Tue, 10 Nov 2009 10:47:03 +0100 Subject: [Xesam] oscaf ontologies: new ontology NSO, moved ontologies to individual pages, maintainers - please get sf accounts In-Reply-To: <1257780623.3474.146.camel@madtablet> References: <4AF70DD6.6010905@dfki.de> <1257780623.3474.146.camel@madtablet> Message-ID: <200911101047.03933.trueg@kde.org> On Monday 09 November 2009 16:30:23 Roberto Guido wrote: > On Sun, 2009-11-08 at 19:28 +0100, Leo Sauermann wrote: > > It is for sharing data and kept very minimal: > > https://sourceforge.net/apps/trac/oscaf/wiki/NSO > > Has this any correlation with this other project about sharing data > among applications? > http://cordis.europa.eu/ictresults/index.cfm?section=news&tpl=article&Brows > ingType=Features&ID=90977 > > No explicit links between the two efforts emerges, this is just a > personal intuition due the common target (an ontology to share data > between applications) and similar involved resources. > no, there is no relation whatsoever. Would that project be interesting for us? Cheers, Sebastian From trueg at kde.org Tue Nov 10 02:23:33 2009 From: trueg at kde.org (Sebastian =?iso-8859-1?q?Tr=FCg?=) Date: Tue, 10 Nov 2009 11:23:33 +0100 Subject: [Xesam] Base ontologies converted to trig -> please verify Message-ID: <200911101123.33423.trueg@kde.org> Hello guys, I finished converting the base ontologies rdf, rdfs, dcterms, dctype, and dces to trig. Please have a look to see if you agree with the way I did it. I will now package the first version of our shared desktop ontologies. Cheers, Sebastian From leo.sauermann at dfki.de Tue Nov 10 09:19:25 2009 From: leo.sauermann at dfki.de (Leo Sauermann) Date: Tue, 10 Nov 2009 18:19:25 +0100 Subject: [Xesam] Base ontologies converted to trig -> please verify In-Reply-To: <200911101123.33423.trueg@kde.org> References: <200911101123.33423.trueg@kde.org> Message-ID: <4AF9A09D.7040202@dfki.de> It was Sebastian Tr?g who said at the right time 10.11.2009 11:23 the following words: > Hello guys, > > I finished converting the base ontologies rdf, rdfs, dcterms, dctype, and dces > to trig. Please have a look to see if you agree with the way I did it. > > I will now package the first version of our shared desktop ontologies. > > Cheers, > Sebastian > > looks fine! how did you convert them? best Leo -- _____________________________________________________ Dr. Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +43 6991 gnowsis D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo.sauermann at dfki.de Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _____________________________________________________ From leo.sauermann at dfki.de Tue Nov 10 09:27:00 2009 From: leo.sauermann at dfki.de (Leo Sauermann) Date: Tue, 10 Nov 2009 18:27:00 +0100 Subject: [Xesam] upcoming push of release to /ontologies on different server Message-ID: <4AF9A264.3070007@dfki.de> Hi Xesame, Oscaf, To keep you updated: Currently, the server hosting www.semanticdesktop.org is sponsored and administrated by XWiki, who have done so for many years now. St?phane Lauri?re manages this. To manage the updates to the ontologies faster, we are moving the server closer to Xesam/NEPOMUK-KDE/Oscaf, by hosting them on a server controlled by Sven Ruby, the OSCAF foundation coordinator. The new server is the one Sven also uses to host www.oscaf.org Tudor Groza (a NEPOMUK project veteran) from DERI (an OSCAF founding member) is working on this currently and it will take some time. We expect it to work within a week, to be on the safe side we guarantee it to work within two weeks. Then the ontologies developed at oscaf.sf.net will be served from the new server at the correct namespace. There may be some glitches in DNS propagation, as usually. This does not stop us from doing a proper release of the ontologies as KDE package anytime, it just helps to have them semantic-web standard conformantly hosted on a HTTP server under the namespace they use. [1] if you have questions, pose them on the mailinglist. best Leo -- _____________________________________________________ Dr. Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +43 6991 gnowsis D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo.sauermann at dfki.de Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _____________________________________________________ From trueg at kde.org Tue Nov 10 10:00:10 2009 From: trueg at kde.org (Sebastian Trueg) Date: Tue, 10 Nov 2009 19:00:10 +0100 Subject: [Xesam] Base ontologies converted to trig -> please verify In-Reply-To: <4AF9A09D.7040202@dfki.de> References: <200911101123.33423.trueg@kde.org> <4AF9A09D.7040202@dfki.de> Message-ID: <4AF9AA2A.3070307@kde.org> Hi Leo, Leo Sauermann wrote: > It was Sebastian Tr?g who said at the right time 10.11.2009 11:23 the > following words: >> Hello guys, >> >> I finished converting the base ontologies rdf, rdfs, dcterms, dctype, and dces >> to trig. Please have a look to see if you agree with the way I did it. >> >> I will now package the first version of our shared desktop ontologies. >> >> Cheers, >> Sebastian >> >> > looks fine! how did you convert them? I used some online verifier/converter to turtle and then did the rest manually. Cheers, Sebastian From leo.sauermann at dfki.de Tue Nov 17 11:57:54 2009 From: leo.sauermann at dfki.de (Leo Sauermann) Date: Tue, 17 Nov 2009 20:57:54 +0100 Subject: [Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless In-Reply-To: <200911120546.30318.phreedom.stdin@gmail.com> References: <200911120546.30318.phreedom.stdin@gmail.com> Message-ID: <4B030042.4080001@dfki.de> Hi Peoples, Evgeny - please send all ontology related emails to the xesam list. good news: I found out why we are so slow -- and how to fix that. its because we don't use patches, as every good project does.... how stupid of us. I looked at the tickets and I found that some of the tickets carry an undertone of "something is wrong, can't exactly say what, we need to change everything, I think you guys did the ontologies totally wrong". For example, here: https://sourceforge.net/apps/trac/oscaf/ticket/14 This ticket contains: * a vague request to remove around 15 properties * very vague answers and comments about other properties. * many errors and unprecisely researched assumptions about what may be or what is or what should be done * an undertone saying that the approach of 1:1 compability with existing standards (ID3, EXIF) is totally yesterday and we must move on. This ticket does not contain: * a precise N3 diff of what to remove and what to add to the ontologies (ha, because when you remove a property, you also have to add some comment saying why and what and how to do it now. a "deprecation message", you know.) If your read the discussion, you will notice that this causes us to mix political discussions ("be backward compatible or not") with concrete suggestions ("remove nid3:comments!") with general architecture changes ("we must have equivalent property relations or constraints"). Of course, as now 15 topics are discussed in one ticket, including political minefields, we will never reach agreement quickly. Of course, as you all know, in other projects such tickets would be immediately closed as invalid saying "submit a patch for a single bug and then we can talk". and these other projects took some years to come to this practice, you know how it works.... To spare us more endless discussions, I propose that from now on, we only allow "one issue per ticket and a patch to fix it" the ticket submitter must state her or his change request with a precise N3 statement saying what must be removed and what must be added (a "diff" or "patch") if a submitter does not comply, the ticket is invalid and gone within a minute. if the submitter does comply, a decision can be done within a week, because its only one decision, and its "yes/no". If the answer is "no", the submitter can try again with a slightly changed suggestion in a new ticket. I don't have to remind you that this is how open source patching works, and that patches have the great property that there can be a "yes/no" vote on accepting them, and moving on with life. Also, it is common practice to allow only "one fix per patch". again, you all know why. if you don't agree, please say so and suggest something better. If you do agree, please give some positive feedback and your own view on this, rephrase my improper language and copy this into the wiki page: https://sourceforge.net/apps/trac/oscaf/wiki/OntologyMaintenance and send an answer to this mail. does this help? i hope it does. best Leo It was Evgeny Egorochkin who said at the right time 12.11.2009 04:46 the following words: > Hi fellow Nepomukians, > > You input is needed on this ticket: > http://sourceforge.net/apps/trac/oscaf/ticket/52 > > It involves some Nepomuk fundamentals such as NRL, so I'm trying to get a bit > more feedback than usual. > > Thanks! > > -- Evgeny > -- _____________________________________________________ Dr. Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +43 6991 gnowsis D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo.sauermann at dfki.de Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _____________________________________________________ From bob4job at gmail.com Tue Nov 17 14:12:03 2009 From: bob4job at gmail.com (Roberto Guido) Date: Tue, 17 Nov 2009 23:12:03 +0100 Subject: [Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless In-Reply-To: <4B030042.4080001@dfki.de> References: <200911120546.30318.phreedom.stdin@gmail.com> <4B030042.4080001@dfki.de> Message-ID: <1258495923.3053.167.camel@madtablet> On Tue, 2009-11-17 at 20:57 +0100, Leo Sauermann wrote: > I don't have to remind you that this is how open source patching > works, > and that patches have the great property that there can be a "yes/no" > vote on accepting them, > and moving on with life. > I agree the requirement of a mandatory patch attached to each ticket, but not the decision making process. Code patches are in most situations easily evaluable: it works / it doesn't works. Patches to an abstract model (the ontology) has same probability to be good or bad depending on who evaluate it, and who is involved in discussion. A change is equivalent to an API break: it is easy to strip a function from the code, but may have dramatic conseguences on existing implementations which use that. My alternative: - mandatory patch - notification of all people designed for maintainance and those who have interest about the Nepomuk effort (is it possible to populate an RSS or send a mail to a list when a new ticket is added in the tracker?) - if no comments arrive within a week the patch is accepted/refused, otherwise... Well, I have no alternative for this. Perhaps some constraint about timing may help in discard excessively slow procedures ("the maintainer must take a decision when no one add comments for at least one week, evaluating the modification and all clearly expressed positions"), but I'm not sure about this. -- Roberto -MadBob- Guido http://claimid.com/madbob From antoni.mylka at gmail.com Tue Nov 17 15:43:49 2009 From: antoni.mylka at gmail.com (Antoni Mylka) Date: Wed, 18 Nov 2009 00:43:49 +0100 Subject: [Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless In-Reply-To: <1258495923.3053.167.camel@madtablet> References: <200911120546.30318.phreedom.stdin@gmail.com> <4B030042.4080001@dfki.de> <1258495923.3053.167.camel@madtablet> Message-ID: <4B033535.6010706@gmail.com> Roberto Guido pisze: > On Tue, 2009-11-17 at 20:57 +0100, Leo Sauermann wrote: >> I don't have to remind you that this is how open source patching >> works, >> and that patches have the great property that there can be a "yes/no" >> vote on accepting them, >> and moving on with life. >> > I agree the requirement of a mandatory patch attached to each ticket, > but not the decision making process. Every decision making process involving more than one person is better than done by a single one. > Code patches are in most situations easily evaluable: it works / it > doesn't works. Patches to an abstract model (the ontology) has same > probability to be good or bad depending on who evaluate it, and who is > involved in discussion. > A change is equivalent to an API break: it is easy to strip a function > from the code, but may have dramatic conseguences on existing > implementations which use that. In my case change is not 'equivalent' to an API break, it IS an API break. I generate classes from an ontology, so if something is removed - a field disappears from a class. If the domain or range of a property is changed, suddenly the RDF I create doesn't validate anymore and I get test failures. I know that we need change if we want to move forward, I just think that we should make it really clear what changes are made and when. > My alternative: > - mandatory patch > - notification of all people designed for maintainance and those who > have interest about the Nepomuk effort (is it possible to populate an > RSS or send a mail to a list when a new ticket is added in the tracker?) Oscaf trac already has a timeline RSS feed that contains the "ticket created" and "ticket closed" events. It can be filtered. If you want a feed only with "ticket opened/closed" events, than the url is: https://sourceforge.net/apps/trac/oscaf/timeline?ticket=on&max=50&daysback=90&format=rss And +1 for the mandatory patch. This is going to make many discussions much easier. > - if no comments arrive within a week the patch is accepted/refused, > otherwise... Well, I have no alternative for this. there is hardly any third 'alternative' option to (accepted || refused) :). I think the alternative is between - no commit until accepted - wait indefinitely until someone else bothers to have a look (IMHO the better option), at least two pairs of eyes for each change. Something like the policy in the Kernel source, that every patch is signed off by more than one person. That would be overkill for us, in general an "OK" from someone who is not me should be a minimum. - if no objections made within a week - accept and commit - potentially faster but less dangerous, I'd rather not do it. > Perhaps some constraint about timing may help in discard excessively > slow procedures ("the maintainer must take a decision when no one add > comments for at least one week, evaluating the modification and all > clearly expressed positions"), but I'm not sure about this. That's nice. I think that adding some actual duties to the 'maintainer' post might not be a bad idea. Antoni Mylka antoni.mylka at gmail.com From phreedom.stdin at gmail.com Tue Nov 17 16:57:44 2009 From: phreedom.stdin at gmail.com (Evgeny Egorochkin) Date: Wed, 18 Nov 2009 02:57:44 +0200 Subject: [Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless In-Reply-To: <4B030042.4080001@dfki.de> References: <200911120546.30318.phreedom.stdin@gmail.com> <4B030042.4080001@dfki.de> Message-ID: <200911180257.44336.phreedom.stdin@gmail.com> ? ????????? ?? ??????? 17 ?????? 2009 21:57:54 ????? Leo Sauermann ???????: > Hi Peoples, > > Evgeny - please send all ontology related emails to the xesam list. This was not an email as such. It was a notification about a ticket which I feel needs urgent resolution and it isn't really related to ontologies themselves, rather backend implementations. I did CC all people who I knew were involved with writing actual code. > good news: > I found out why we are so slow -- and how to fix that. > > its because we don't use patches, as every good project does.... how > stupid of us. > > I looked at the tickets and I found that some of the tickets carry an > undertone of > "something is wrong, can't exactly say what, we need to change > everything, I think you guys did the ontologies totally wrong". > > For example, here: > https://sourceforge.net/apps/trac/oscaf/ticket/14 > This ticket contains: > * a vague request to remove around 15 properties Or you can look at it as a specific list of properties which I propose for removal or merging with their superproperties > * very vague answers and comments about other properties. > * many errors and unprecisely researched assumptions about what may be > or what is or what should be done This is too vague ;) and should be discussed on per-property basis with specific explanations. When there were 2 identical properties I wrote property1 = property2, which is pretty self-explanatory. When there were more complex cases like date and time properties I tried to explain. Taking one specific example you mention, nid3:length: nid3:length a rdf:Property ; rdfs:comment """TLEN The 'Length' frame contains the length of the audiofile in milliseconds, represented as a numeric string.""" ; rdfs:domain nid3:ID3Audio ; rdfs:label "length" ; rdfs:range rdfs:Literal . The posible issues are: * type of nfo:duration. xsd:duration can store fractional seconds, and milliseconds as a consequence * preserving the original content of the property in a literal instead of extracting the value. This really matters only if the value is malformed. I don't think this is useful. If our specialized ID3 extractor can't make sense of the contents of the property, it's very unlikely that any other application will. If there are any other issues with nid3:length that I missed, please list them. > * an undertone saying that the approach of 1:1 compability with existing > standards (ID3, EXIF) is totally yesterday and we must move on. It's not about yesterday, it's about something being convenient to us. If there's already an established ontology like http://www.kanzaki.com/ns/exif I don't mind using it for compatibility with the outside world, but as you say inference is cheap which means we don't have to be tied to it. I think making our ontologies interoperate seamlessly is a higher priority than seamless interoperation with outside ontologies. > This ticket does not contain: > * a precise N3 diff of what to remove and what to add to the ontologies > (ha, because when you remove a property, you also have to add some > comment saying why and what and how to do it now. a "deprecation > message", you know.) The process of deprecation wasn't established and even discussed at that time. When we actually decided to deprecate something [1], I filed one more ticket to establish the proper way to do this [2] [1] https://sourceforge.net/apps/trac/oscaf/ticket/32 [2] https://sourceforge.net/apps/trac/oscaf/ticket/37 > If your read the discussion, you will notice that this causes us to mix > political discussions ("be backward compatible or not") with concrete > suggestions ("remove nid3:comments!") with general architecture changes > ("we must have equivalent property relations or constraints"). > > Of course, as now 15 topics are discussed in one ticket, including > political minefields, we will never reach agreement quickly. > Of course, as you all know, in other projects such tickets would be > immediately closed as invalid saying > "submit a patch for a single bug and then we can talk". > and these other projects took some years to come to this practice, you > know how it works.... This is a problem indeed. There's however another problem: regardless of if you file 1 ticket or 10 tickets for each minor detail, they still remain closely related. You can't just close one without considering the rest. So my approach was to post a "discussion" or RFC ticket to put everything into perspective and then split it into smaller and more specific issues. Hopefully this eventually leads to documenting the entire decision space and a correct solution to the problem. The ticket in question is tightly related or has directly caused the following, more specific, tickets: https://sourceforge.net/apps/trac/oscaf/ticket/35 https://sourceforge.net/apps/trac/oscaf/ticket/42 https://sourceforge.net/apps/trac/oscaf/ticket/52 > To spare us more endless discussions, I propose that from now on, we > only allow > > "one issue per ticket and a patch to fix it" Mandating a patch isn't necessarily a good idea. Taking it to extreme, consider a patch that would suggest using someother:string instead of xsd:string. Compare the patch itself with its human-readable description. The effort to make the patch and the fact that *the patch has to be verified for correctness* and the easiest way to do this for a maintainer is take the textual description and make the patch himself. It's often easier to read an explanation than the patch itself. A real-world example would be NDO [3] which came with a patch, was a good idea but it got totally reworked. [3] https://sourceforge.net/apps/trac/oscaf/ticket/4 > the ticket submitter must state her or his change request with a precise > N3 statement saying what must be removed and what must be added > (a "diff" or "patch") Requiring patches is even more unfriendly to people outside of the core developers. You really need to know how everything fits together to make a proper patch which means that contributed patches will either way be discarded or reworked. > if a submitter does not comply, the ticket is invalid and gone within a > minute. One more thing that projects accept gladly is feature requests. No they don't come with patches > if the submitter does comply, a decision can be done within a week, > because its only one decision, and its "yes/no". > If the answer is "no", the submitter can try again with a slightly > changed suggestion in a new ticket. Which doesn't mean the discussion takes less time. You simply have more tickets with a faster turnaround. > I don't have to remind you that this is how open source patching works, > and that patches have the great property that there can be a "yes/no" > vote on accepting them, > and moving on with life. A "no" may mean the patch should be modified, which means discussion. The discussion has to take place somewhere. One of ontology maintenance policies [4] we have ATM says "No ticket - no commit policy. This is important to document our decisions. Every change must be discussed in the issue tracker before being committed. Every comment of parties affected by the decision must be posted to the ticket regardless of the way the comment was communicated(email, conference etc). The exception to this policy is minor technical defects such as typos and formatting." I have intentionally formulated it this way to concentrate all discussions and opinions in a single place: issue tracker. If you enforce the patch policy it means that initial discussion and feature request happens elsewhere which makes it harder to find out why something was done the way it was done. You could try an mark discussion tickets somehow like adding another ticket type: discussion. But then you can discuss defects, enchancements, tasks so it's not entirely correct. Either way I'm not pretending the current policies are perfect, just explaning why they are like this. [4] https://sourceforge.net/apps/trac/oscaf/wiki/OntologyMaintenance > Also, it is common practice to allow only "one fix per patch". > again, you all know why. I agree with this. If there are several independent matters, it makes sense to make several commits. > if you don't agree, > please say so and suggest something better. > > If you do agree, > please give some positive feedback and your own view on this, > rephrase my improper language and copy this into the wiki page: > https://sourceforge.net/apps/trac/oscaf/wiki/OntologyMaintenance > > and send an answer to this mail. > > does this help? > i hope it does. > > best > Leo > > > > It was Evgeny Egorochkin who said at the right time 12.11.2009 04:46 the > > following words: > > Hi fellow Nepomukians, > > > > You input is needed on this ticket: > > http://sourceforge.net/apps/trac/oscaf/ticket/52 > > > > It involves some Nepomuk fundamentals such as NRL, so I'm trying to get a > > bit more feedback than usual. > > > > Thanks! > > > > -- Evgeny > From phreedom.stdin at gmail.com Tue Nov 17 17:10:31 2009 From: phreedom.stdin at gmail.com (Evgeny Egorochkin) Date: Wed, 18 Nov 2009 03:10:31 +0200 Subject: [Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless In-Reply-To: <1258495923.3053.167.camel@madtablet> References: <200911120546.30318.phreedom.stdin@gmail.com> <4B030042.4080001@dfki.de> <1258495923.3053.167.camel@madtablet> Message-ID: <200911180310.31817.phreedom.stdin@gmail.com> ? ????????? ?? ????? 18 ?????? 2009 00:12:03 ????? Roberto Guido ???????: > On Tue, 2009-11-17 at 20:57 +0100, Leo Sauermann wrote: > > I don't have to remind you that this is how open source patching > > works, > > and that patches have the great property that there can be a "yes/no" > > vote on accepting them, > > and moving on with life. > > I agree the requirement of a mandatory patch attached to each ticket, > but not the decision making process. > > Code patches are in most situations easily evaluable: it works / it > doesn't works. Patches to an abstract model (the ontology) has same > probability to be good or bad depending on who evaluate it, and who is > involved in discussion. > A change is equivalent to an API break: it is easy to strip a function > from the code, but may have dramatic conseguences on existing > implementations which use that. Form my experience, it's almost impossible to come up with a working patch when suggesting something significant and especially when requesting a feature. There are often lots of possible ways to implement something and without the initial discussion, you get a 95% useless patch, especially if you aren't a core developer. For more comments read my reply to Leo. > My alternative: > - mandatory patch > - notification of all people designed for maintainance and those who > have interest about the Nepomuk effort (is it possible to populate an > RSS or send a mail to a list when a new ticket is added in the tracker?) Having a mailing list with some notifications is a good idea indeed. > - if no comments arrive within a week the patch is accepted/refused, > otherwise... Well, I have no alternative for this. This works only for trivial patches which require fast resolution. We have a milestone: good idea for later for a reason. > Perhaps some constraint about timing may help in discard excessively > slow procedures ("the maintainer must take a decision when no one add > comments for at least one week, evaluating the modification and all > clearly expressed positions"), but I'm not sure about this. The current policy is: "Ontology maintainers are responsible for ensuring that decisions meet consensus criteria. This means either: * Waiting long enough for all parties involved to either comment or ignore the issue(considered an abstention). * Contacting all affected parties to obtain either their comment, confirm their abstention or to set a deadline for them to express their opinion. As a consequence of being responsible, commits to the repository need a maintainer approval." The only obvious fix would be to clarify "waiting long enough". At this moment this vague phrase probably means a couple of months. The implications of the fix would probably be: milestones and priorities influence what maintainers do first; maintainers can politely "demand" affected parties to cooperate on the current issues. -- Evgeny From sebastian.faubel at gmail.com Wed Nov 18 03:29:23 2009 From: sebastian.faubel at gmail.com (Sebastian Faubel) Date: Wed, 18 Nov 2009 12:29:23 +0100 Subject: [Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless In-Reply-To: <200911180310.31817.phreedom.stdin@gmail.com> References: <200911120546.30318.phreedom.stdin@gmail.com> <4B030042.4080001@dfki.de> <1258495923.3053.167.camel@madtablet> <200911180310.31817.phreedom.stdin@gmail.com> Message-ID: <1258543763.4035.15.camel@cassiopeia> > Form my experience, it's almost impossible to come up with a working patch > when suggesting something significant and especially when requesting a feature. > > There are often lots of possible ways to implement something and without the > initial discussion, you get a 95% useless patch, especially if you aren't a > core developer. I agree to the above mentioned - It should not be mandatory to send in a patch when filing a bug report. However, a patch can often serve as a concrete starting point for discussion on the mailing list. I mean, that from a patch people can outline concrete modeling weaknesses and offer concrete resolutions. One difficulty when designing ontologies is not to get off topic and stay focused on the problem at hand. I think that this is what really needs to be addressed. I think it would be best to put a notification text on the bug filing form to encourage people to provide patches for the bugs in order to get them fixed more quickly. May be it could be helpful if the ontology maintainers provide an initial patch when conducting the mailing list in all cases. > For more comments read my reply to Leo. > > > My alternative: > > - mandatory patch > > - notification of all people designed for maintainance and those who > > have interest about the Nepomuk effort (is it possible to populate an > > RSS or send a mail to a list when a new ticket is added in the tracker?) > > Having a mailing list with some notifications is a good idea indeed. > > > - if no comments arrive within a week the patch is accepted/refused, > > otherwise... Well, I have no alternative for this. > > This works only for trivial patches which require fast resolution. We have a > milestone: good idea for later for a reason. > > > Perhaps some constraint about timing may help in discard excessively > > slow procedures ("the maintainer must take a decision when no one add > > comments for at least one week, evaluating the modification and all > > clearly expressed positions"), but I'm not sure about this. > > The current policy is: > > "Ontology maintainers are responsible for ensuring that decisions meet > consensus criteria. This means either: > * Waiting long enough for all parties involved to either comment or ignore the > issue(considered an abstention). > * Contacting all affected parties to obtain either their comment, confirm their > abstention or to set a deadline for them to express their opinion. As a > consequence of being responsible, commits to the repository need a maintainer > approval." > > The only obvious fix would be to clarify "waiting long enough". At this moment > this vague phrase probably means a couple of months. > > The implications of the fix would probably be: milestones and priorities > influence what maintainers do first; maintainers can politely "demand" affected > parties to cooperate on the current issues. > > -- Evgeny > _______________________________________________ > Xesam mailing list > Xesam at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xesam From antoni.mylka at gmail.com Thu Nov 19 02:45:05 2009 From: antoni.mylka at gmail.com (Antoni Mylka) Date: Thu, 19 Nov 2009 11:45:05 +0100 Subject: [Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless In-Reply-To: <1258543763.4035.15.camel@cassiopeia> References: <200911120546.30318.phreedom.stdin@gmail.com> <4B030042.4080001@dfki.de> <1258495923.3053.167.camel@madtablet> <200911180310.31817.phreedom.stdin@gmail.com> <1258543763.4035.15.camel@cassiopeia> Message-ID: <4B0521B1.3080008@gmail.com> Sebastian Faubel pisze: >> Form my experience, it's almost impossible to come up with a working patch >> when suggesting something significant and especially when requesting a feature. >> >> There are often lots of possible ways to implement something and without the >> initial discussion, you get a 95% useless patch, especially if you aren't a >> core developer. > > I agree to the above mentioned - It should not be mandatory to send in a > patch when filing a bug report. However, a patch can often serve as a > concrete starting point for discussion on the mailing list. I mean, that > from a patch people can outline concrete modeling weaknesses and offer > concrete resolutions. One difficulty when designing ontologies is not to > get off topic and stay focused on the problem at hand. I think that this > is what really needs to be addressed. +1. Discussing a patch is much easier. Even if the initial version is 95% incorrect. We shouldn't require it, because that would alienate potential external contributors. We should seriously encourage it though at least among ourselves. Antoni Mylka antoni.mylka at gmail.com From antoni.mylka at gmail.com Thu Nov 19 03:25:48 2009 From: antoni.mylka at gmail.com (Antoni Mylka) Date: Thu, 19 Nov 2009 12:25:48 +0100 Subject: [Xesam] Notifications Message-ID: <4B052B3C.5030201@gmail.com> Xesamies, I've taken a look at the "notifications" page of the Trac admin interface. There is an option 'smtp_always_cc', which could be set to send all notifications to the mailing list. Should I set it, or do you prefer to get only notifications for those tickets you specifically subscribe to. It's important because the timeline RSS contains everything BUT the individual ticket comments, and ticket comments is where the real fun is :). When this option is set, whenever a notification is directly for you, you might get it both directly and via a mailing list. Antoni Mylka antoni.mylka at gmail.com From bob4job at gmail.com Thu Nov 19 03:55:52 2009 From: bob4job at gmail.com (Roberto Guido) Date: Thu, 19 Nov 2009 12:55:52 +0100 Subject: [Xesam] Notifications In-Reply-To: <4B052B3C.5030201@gmail.com> References: <4B052B3C.5030201@gmail.com> Message-ID: <1258631752.23370.19.camel@madtablet> On Thu, 2009-11-19 at 12:25 +0100, Antoni Mylka wrote: > It's important because the timeline RSS contains everything BUT the > individual ticket comments, and ticket comments is where the real fun > is :). > I prefer avoid redirection of each notification to the mailing list due: - unrequired traffic - risk to split discussions between bugtracker and mailing list, generating great caos RSS reports only creation of new tickets, and this is what I think is important: people can be notified when something new happens, and then choose to subscribe the ticket in trac or simply ignore because not in the field of interest. -- Roberto -MadBob- Guido http://claimid.com/madbob From leo.sauermann at dfki.de Fri Nov 20 13:32:06 2009 From: leo.sauermann at dfki.de (Leo Sauermann) Date: Fri, 20 Nov 2009 22:32:06 +0100 Subject: [Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless In-Reply-To: <4B0521B1.3080008@gmail.com> References: <200911120546.30318.phreedom.stdin@gmail.com> <4B030042.4080001@dfki.de> <1258495923.3053.167.camel@madtablet> <200911180310.31817.phreedom.stdin@gmail.com> <1258543763.4035.15.camel@cassiopeia> <4B0521B1.3080008@gmail.com> Message-ID: <4B070AD6.80100@dfki.de> ok, summary from my side: * patches are a welcome idea by Antoni, Sebastian, Evgeny, Roberto, but some say: not mandatory. * maintainer has to reply to a patch within a week. agreed? (if all say yes, we work like this from now on) I would also say: patches do not have to be perfect, something like this is enough: "change nco: add: nco:PersonContact rdfs:subClassOf banana:Bananas. nco:Contact rdfs:comment "All persons are bananas in their brains." " We have an ontology language (RDFS, NRL and N3) for a reason: it gives us a clear langauge to speak. Such text is easy to write, but much more precise than prose. all ok? the input and dicussion is good, we get somewhere, best Leo It was Antoni Mylka who said at the right time 19.11.2009 11:45 the following words: > Sebastian Faubel pisze: > >>> Form my experience, it's almost impossible to come up with a working patch >>> when suggesting something significant and especially when requesting a feature. >>> >>> There are often lots of possible ways to implement something and without the >>> initial discussion, you get a 95% useless patch, especially if you aren't a >>> core developer. >>> >> I agree to the above mentioned - It should not be mandatory to send in a >> patch when filing a bug report. However, a patch can often serve as a >> concrete starting point for discussion on the mailing list. I mean, that >> from a patch people can outline concrete modeling weaknesses and offer >> concrete resolutions. One difficulty when designing ontologies is not to >> get off topic and stay focused on the problem at hand. I think that this >> is what really needs to be addressed. >> > > +1. Discussing a patch is much easier. Even if the initial version is > 95% incorrect. We shouldn't require it, because that would alienate > potential external contributors. We should seriously encourage it though > at least among ourselves. > > Antoni Mylka > antoni.mylka at gmail.com > _______________________________________________ > Xesam mailing list > Xesam at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xesam > -- _____________________________________________________ Dr. Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +43 6991 gnowsis D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo.sauermann at dfki.de Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _____________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/xesam/attachments/20091120/af32421c/attachment.html From leo.sauermann at dfki.de Fri Nov 20 13:35:06 2009 From: leo.sauermann at dfki.de (Leo Sauermann) Date: Fri, 20 Nov 2009 22:35:06 +0100 Subject: [Xesam] Notifications In-Reply-To: <1258631752.23370.19.camel@madtablet> References: <4B052B3C.5030201@gmail.com> <1258631752.23370.19.camel@madtablet> Message-ID: <4B070B8A.8070808@dfki.de> It was Roberto Guido who said at the right time 19.11.2009 12:55 the following words: > On Thu, 2009-11-19 at 12:25 +0100, Antoni Mylka wrote: > >> It's important because the timeline RSS contains everything BUT the >> individual ticket comments, and ticket comments is where the real fun >> is :). >> >> > I prefer avoid redirection of each notification to the mailing list due: > - unrequired traffic > - risk to split discussions between bugtracker and mailing list, > generating great caos > in my view this is no risk discussion should not take place in mailinglist, but in tickets. tickets are documentation that stays, mailinglists are the limbo of time flown by our eyes and lost in google, forever going on their meandering ways.... so I am for "send it to the list" but if I am the only one, I would not activate that. (on the other hand, we can try and then switch it off again later if someone hates it) best Leo > RSS reports only creation of new tickets, and this is what I think is > important: people can be notified when something new happens, and then > choose to subscribe the ticket in trac or simply ignore because not in > the field of interest. > > -- _____________________________________________________ Dr. Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +43 6991 gnowsis D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo.sauermann at dfki.de Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _____________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/xesam/attachments/20091120/78805ec5/attachment.htm From trueg at kde.org Mon Nov 23 05:47:05 2009 From: trueg at kde.org (Sebastian Trueg) Date: Mon, 23 Nov 2009 14:47:05 +0100 Subject: [Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless In-Reply-To: <4B070AD6.80100@dfki.de> References: <200911120546.30318.phreedom.stdin@gmail.com> <4B030042.4080001@dfki.de> <1258495923.3053.167.camel@madtablet> <200911180310.31817.phreedom.stdin@gmail.com> <1258543763.4035.15.camel@cassiopeia> <4B0521B1.3080008@gmail.com> <4B070AD6.80100@dfki.de> Message-ID: <4B0A9259.5010004@kde.org> Leo Sauermann wrote: > ok, summary from my side: > > * patches are a welcome idea by Antoni, Sebastian, Evgeny, Roberto, > but some say: not mandatory. > > * maintainer has to reply to a patch within a week. > agreed? > (if all say yes, we work like this from now on) > > > I would also say: > patches do not have to be perfect, something like this is enough: > > "change nco: > add: > nco:PersonContact rdfs:subClassOf banana:Bananas. > nco:Contact rdfs:comment "All persons are bananas in their brains." > " > > We have an ontology language (RDFS, NRL and N3) for a reason: it gives > us a clear langauge to speak. > Such text is easy to write, but much more precise than prose. > > all ok? fine by me. :) From phreedom.stdin at gmail.com Mon Nov 23 16:16:01 2009 From: phreedom.stdin at gmail.com (Evgeny Egorochkin) Date: Tue, 24 Nov 2009 02:16:01 +0200 Subject: [Xesam] NRL; Need your input - Leo proposes to allow from now on only "one patch per ticket" because we are slow and discussion is endless In-Reply-To: <4B070AD6.80100@dfki.de> References: <200911120546.30318.phreedom.stdin@gmail.com> <4B0521B1.3080008@gmail.com> <4B070AD6.80100@dfki.de> Message-ID: <200911240216.01551.phreedom.stdin@gmail.com> ? ????????? ?? ??????? 20 ?????? 2009 23:32:06 ????? Leo Sauermann ???????: > ok, summary from my side: > > * patches are a welcome idea by Antoni, Sebastian, Evgeny, Roberto, > but some say: not mandatory. +1 as long as it's defined as: provide patch if possible/applies to the situation/can be useful, > * maintainer has to reply to a patch within a week. > agreed? > (if all say yes, we work like this from now on) Some questions: * I can afford to promise this. Can others like Antoni afford? * Maintainer = one of maintainers or all maintainers? * What if the only reasonable course of actions is to first obtain feedback from parties affected? Or this means that all maintainers must take some action(like clarify the question, ask for feedback) in case if this is needed within 1 week? How about tickets stalled due to lack of follow up from the reporter or one of implementations(where required)? To be honest, I'm DESPERATELY LOOKING FOR an excuse to be able to make changes faster. In the current situation, there's a chance this would mean: * me proposing a patch(X% of the time based on someone asking/complaining about something; (100-X)% of time because I see this biting us in the ass later) * me replying that I like the patch and * me making the commit and closing ticket. Essentially no peer review or feedback. > I would also say: > patches do not have to be perfect, something like this is enough: > > "change nco: > add: > nco:PersonContact rdfs:subClassOf banana:Bananas. > nco:Contact rdfs:comment "All persons are bananas in their brains." > " > > We have an ontology language (RDFS, NRL and N3) for a reason: it gives > us a clear langauge to speak. > Such text is easy to write, but much more precise than prose. +1 If you are allowed to use some human (but precisely worded) language when it makes sense. eg: use xxx:string intead of xsd:string all across the ontology. The preference of course goes to specific lists of triples to add/remove. > all ok? > > the input and dicussion is good, we get somewhere, > best > Leo > > > > > It was Antoni Mylka who said at the right time 19.11.2009 11:45 the > > following words: > > Sebastian Faubel pisze: > >>> Form my experience, it's almost impossible to come up with a working > >>> patch when suggesting something significant and especially when > >>> requesting a feature. > >>> > >>> There are often lots of possible ways to implement something and > >>> without the initial discussion, you get a 95% useless patch, especially > >>> if you aren't a core developer. > >> > >> I agree to the above mentioned - It should not be mandatory to send in a > >> patch when filing a bug report. However, a patch can often serve as a > >> concrete starting point for discussion on the mailing list. I mean, that > >> from a patch people can outline concrete modeling weaknesses and offer > >> concrete resolutions. One difficulty when designing ontologies is not to > >> get off topic and stay focused on the problem at hand. I think that this > >> is what really needs to be addressed. > > > > +1. Discussing a patch is much easier. Even if the initial version is > > 95% incorrect. We shouldn't require it, because that would alienate > > potential external contributors. We should seriously encourage it though > > at least among ourselves. > > > > Antoni Mylka > > antoni.mylka at gmail.com > > _______________________________________________ > > Xesam mailing list > > Xesam at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/xesam > -- Evgeny From leo.sauermann at dfki.de Tue Nov 24 00:23:53 2009 From: leo.sauermann at dfki.de (Leo Sauermann) Date: Tue, 24 Nov 2009 09:23:53 +0100 Subject: [Xesam] [Oscaf] First shared-desktop-ontologies tarball test In-Reply-To: <4B0A5F8F.1050106@kde.org> References: <4B0A5F8F.1050106@kde.org> Message-ID: <4B0B9819.4010409@dfki.de> License: Ontology files are both prosa (=text) and software. Years ago we thought it would therefore be wise to double-license ontologies as CC-BY and BSD. this is also the license that was since many months here: https://sourceforge.net/apps/trac/oscaf/wiki/License why didn't you copy it from there? - any reasons to ignore the wiki page or weren't you aware of it? anyway, I am also fine bith BSD, if everyone else agrees that "in the future, double-licensing is ok". but then, change the wiki page. Folders: the "base" folder may bite us back later. i.e. it contains a mix of ontologies we consider "base" such as dcterms and rdf and rdfs. someone may ask: why is OWL not there? why is skos not there? (etc.) so we * _may_ change it to subfolders "rdfs" "rdf", "dcterms", etc.... - would be more "correct". * leave as is and go on - I prefer that. if other people ship other ontologies as installation packages, they can come up with other top-folder names besides shared-desktop-ontologies name: for the sake of saying it: I of course hold the flag up and say "we should call them shared-oscaf-ontologies" but I am of course as happy with the current name. best Leo It was Sebastian Trueg who said at the right time 23.11.2009 11:10 the following words: > Hi guys, > > please find attached a tarball with a simple cmake-based build system > which installs all ontologies into /share/ontology using a few > subfolders for a cleaner layout. > As KDE 4.4 is frozen on Wednesday I need at least a preview release to > make kde depend on. Thus, the installation dir should be fixed already. > Everything else we can change at one point or the other. > > So please have a look and comment on: > - the installation target dir and the subfolders > - the name of the package > > I will ignore comments about: > - the build system (as I said: we can change that and by "we" I mean > whoever complains) > - the missing documentation (can be added later) > > We also need to decide on the license. I proposed something modeled on > BSD on irc: > > # > # Copyright > # > # Redistribution and use in any serialization form, with or without > # modification, are permitted provided that the following condition > # is met: > # > # Redistributions of the ontology in any form must retain the above > # copyright notice, this list of conditions and the following disclaimer. > # > # THIS ONTOLOGY IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR > # IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES > # OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. > # IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, > # INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > # NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > # DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > # THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > # THIS ONTOLOGY, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > # > > If you have other ideas please say so and post the header to be included > in the files. I will not write it for you! This also means that comments > like "I vote for a XXX-compatible license" or "let's use license A" will > be ignored if they are not accompanied by a piece of text like the above > that I can directly copy into the files. > > Thanks for participating. > > Cheers, > Sebastian > > ------------------------------------------------------------------------ > > _______________________________________________ > Oscaf mailing list > Oscaf at lists.deri.org > http://lists.deri.org/mailman/listinfo/oscaf > -- _____________________________________________________ Dr. Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +43 6991 gnowsis D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo.sauermann at dfki.de Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _____________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/xesam/attachments/20091124/e6c70df9/attachment.html From ivan.frade at gmail.com Tue Nov 24 05:09:14 2009 From: ivan.frade at gmail.com (Ivan Frade) Date: Tue, 24 Nov 2009 15:09:14 +0200 Subject: [Xesam] [Oscaf] First shared-desktop-ontologies tarball test In-Reply-To: <4B0B9819.4010409@dfki.de> References: <4B0A5F8F.1050106@kde.org> <4B0B9819.4010409@dfki.de> Message-ID: Hi, On Tue, Nov 24, 2009 at 10:23 AM, Leo Sauermann wrote: > License: > Ontology files are both prosa (=text) and software. > Years ago we thought it would therefore be wise to double-license > ontologies as CC-BY and BSD. > this is also the license that was since many months here: > https://sourceforge.net/apps/trac/oscaf/wiki/License > why didn't you copy it from there? - any reasons to ignore the wiki page or > weren't you aware of it? > That is not the license stated in the Nepomuk official web page: http://www.semanticdesktop.org/ontologies/nfo/LICENSE.txt I am confused. Regards, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/xesam/attachments/20091124/5ff9b94e/attachment.htm From trueg at kde.org Tue Nov 24 05:48:42 2009 From: trueg at kde.org (Sebastian =?iso-8859-1?q?Tr=FCg?=) Date: Tue, 24 Nov 2009 14:48:42 +0100 Subject: [Xesam] [Oscaf] First shared-desktop-ontologies tarball test In-Reply-To: <4B0B9819.4010409@dfki.de> References: <4B0A5F8F.1050106@kde.org> <4B0B9819.4010409@dfki.de> Message-ID: <200911241448.42457.trueg@kde.org> On Tuesday 24 November 2009 09:23:53 Leo Sauermann wrote: > License: > Ontology files are both prosa (=text) and software. > Years ago we thought it would therefore be wise to double-license > ontologies as CC-BY and BSD. > this is also the license that was since many months here: > https://sourceforge.net/apps/trac/oscaf/wiki/License > why didn't you copy it from there? - any reasons to ignore the wiki page > or weren't you aware of it? I was not aware of that page. Thanks for pointing it out. I am fine with that header, too. So here goes an updated header (which I will also update on the wiki once agreed): # # Copyright (c) , # All rights reserved, licensed under either CC-BY or BSD. # # You are free: # * to Share - to copy, distribute and transmit the work # * to Remix - to adapt the work # Under the following conditions: # * Attribution - You must attribute the work in the manner specified by the author # or licensor (but not in any way that suggests that they endorse you or your use # of the work). # # Redistribution and use in source and binary forms, with or without modification, # are permitted provided that the following conditions are met: # * Redistributions of source code must retain the above copyright notice, this # list of conditions and the following disclaimer. # * Redistributions in binary form must reproduce the above copyright notice, this # list of conditions and the following disclaimer in the documentation and/or # other materials provided with the distribution. # * Neither the names of the authors nor the names of contributors may # be used to endorse or promote products derived from this ontology without # specific prior written permission. # # THIS ONTOLOGY IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR # IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES # OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. # IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, # INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT # NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, # DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY # THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF # THIS ONTOLOGY, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # > anyway, I am also fine bith BSD, if everyone else agrees that "in the > future, double-licensing is ok". > but then, change the wiki page. > > Folders: > the "base" folder may bite us back later. > i.e. it contains a mix of ontologies we consider "base" such as dcterms > and rdf and rdfs. > someone may ask: why is OWL not there? why is skos not there? > (etc.) > so we > * _may_ change it to subfolders "rdfs" "rdf", "dcterms", etc.... - would > be more "correct". > * leave as is and go on - I prefer that. if other people ship other > ontologies as installation packages, they can come up with other > top-folder names besides shared-desktop-ontologies The idea of the "base" folder was to put anything in there that is not maintained by us. So maybe "3rdparty" would be a better name although that looks ugly. Cheers, Sebastian > name: > for the sake of saying it: I of course hold the flag up and say "we > should call them shared-oscaf-ontologies" but I am of course as happy > with the current name. > > best > Leo > > > It was Sebastian Trueg who said at the right time 23.11.2009 11:10 the > > following words: > > Hi guys, > > > > please find attached a tarball with a simple cmake-based build system > > which installs all ontologies into /share/ontology using a few > > subfolders for a cleaner layout. > > As KDE 4.4 is frozen on Wednesday I need at least a preview release to > > make kde depend on. Thus, the installation dir should be fixed already. > > Everything else we can change at one point or the other. > > > > So please have a look and comment on: > > - the installation target dir and the subfolders > > - the name of the package > > > > I will ignore comments about: > > - the build system (as I said: we can change that and by "we" I mean > > whoever complains) > > - the missing documentation (can be added later) > > > > We also need to decide on the license. I proposed something modeled on > > BSD on irc: > > > > # > > # Copyright > > # > > # Redistribution and use in any serialization form, with or without > > # modification, are permitted provided that the following condition > > # is met: > > # > > # Redistributions of the ontology in any form must retain the above > > # copyright notice, this list of conditions and the following disclaimer. > > # > > # THIS ONTOLOGY IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR > > # IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED > > WARRANTIES # OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE > > DISCLAIMED. # IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, > > INDIRECT, # INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES > > (INCLUDING, BUT # NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR > > SERVICES; LOSS OF USE, # DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > > HOWEVER CAUSED AND ON ANY # THEORY OF LIABILITY, WHETHER IN CONTRACT, > > STRICT LIABILITY, OR TORT # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING > > IN ANY WAY OUT OF THE USE OF # THIS ONTOLOGY, EVEN IF ADVISED OF THE > > POSSIBILITY OF SUCH DAMAGE. # > > > > If you have other ideas please say so and post the header to be included > > in the files. I will not write it for you! This also means that comments > > like "I vote for a XXX-compatible license" or "let's use license A" will > > be ignored if they are not accompanied by a piece of text like the above > > that I can directly copy into the files. > > > > Thanks for participating. > > > > Cheers, > > Sebastian > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Oscaf mailing list > > Oscaf at lists.deri.org > > http://lists.deri.org/mailman/listinfo/oscaf > From trueg at kde.org Tue Nov 24 05:59:46 2009 From: trueg at kde.org (Sebastian Trueg) Date: Tue, 24 Nov 2009 14:59:46 +0100 Subject: [Xesam] [Oscaf] First shared-desktop-ontologies tarball test In-Reply-To: References: <4B0A5F8F.1050106@kde.org> <4B0B9819.4010409@dfki.de> Message-ID: <4B0BE6D2.3080307@kde.org> Actually it sort of is. I took BSD (the license you refer to) and tried to adjust it to ontologies. Probably not the best idea. Anyway, the source is the same and my other email contains the updated license header based on the decision we apparently took a few months ago. Cheers, Sebastian Ivan Frade wrote: > Hi, > > On Tue, Nov 24, 2009 at 10:23 AM, Leo Sauermann > wrote: > > License: > Ontology files are both prosa (=text) and software. > Years ago we thought it would therefore be wise to double-license > ontologies as CC-BY and BSD. > this is also the license that was since many months here: > https://sourceforge.net/apps/trac/oscaf/wiki/License > why didn't you copy it from there? - any reasons to ignore the wiki > page or weren't you aware of it? > > > That is not the license stated in the Nepomuk official web page: > > http://www.semanticdesktop.org/ontologies/nfo/LICENSE.txt > > I am confused. > > Regards, > > Ivan > From trueg at kde.org Tue Nov 24 06:25:21 2009 From: trueg at kde.org (Sebastian Trueg) Date: Tue, 24 Nov 2009 15:25:21 +0100 Subject: [Xesam] [Oscaf] First shared-desktop-ontologies tarball test In-Reply-To: <1259072179.3515.14.camel@cassiopeia> References: <4B0A5F8F.1050106@kde.org> <4B0B9819.4010409@dfki.de> <200911241448.42457.trueg@kde.org> <1259072179.3515.14.camel@cassiopeia> Message-ID: <4B0BECD1.1080407@kde.org> Sebastian Faubel wrote: >> The idea of the "base" folder was to put anything in there that is not >> maintained by us. So maybe "3rdparty" would be a better name although that >> looks ugly. > > May be you could call it "external"? Does also not look pretty, but may > be prettier than "3rdparty". Personally, I'm fine with calling it > "base". "external" is not bad either. But in the end this is not that important as we can easily change that even after a release.