Dear Chryssoula, > I think the issues you mentioned are under the numbers 156 and 229, and > these issues are on the list.
I stand corrected: issue 229 is the one I was talking about. Issue 156 has in fact introduced the bug, since it generalized P39 without generalizing P43. Since the title of issue 229 is merely "Correcting issue 156" and there is no effective search on the issue list, it's quite hard to find :-) Which underscores the need for better issue management tooling. If we have better tools for managing issues (e.g. ability to tag by Entity and Property number; easily refer to issues in discussions, etc) then people will refer more often to issues and the respective decisions, and our discussions will be a lot more effective. Dear Martin, > If you know of access to suitable S/W, that would be most welcome. > We also appreciate co-development. Previously I gave two examples (the W3C tools, and Jira). We should have a discussion with people interested in these "mundane" matters, and pick a tool and deploy it. I don’t think we should develop an issue tracker. > We can coordinate, but not do all jobs. The solution is concentrating > forces with a tight communication and participation, avoiding diverging > activities. Agree! It's not my intention to create any diverging efforts. (But it is my intention to drive practical RDF issues aggressively, since for me there's no CRM but RDF-represented CRM :-) If we win that COST action, it will provide some funding for the better running of these efforts. > I'd regard it as unlucky, if you and other partners > interested could not participate in the next CRM-SIG meeting. For me the problem is funding! COST will pay for these trips, and make it easier for all interested parties to attend: 2 people per country being COST action members (so-called Management Committee); plus any other experts that the MC decides to invite. At the same time, we should improve electronic working. > We are aware that the recording of the justifications of decisions could > be improved. > We have discussed sound recording. However, writing such > minutes requires considerable time and skills. We would VERY much > appreciate if more partners would contribute to minutes writing. > This is currently our bottle neck. Also: currently all important CRM decisions are taken in face-to-face meetings, which I think is unfortunate. W3C groups do most of their work through regular online meetings (weekly, biweekly: depending on the intensity of working on a specific spec). The W3C has mastered the collaborative creation of specifications of huge public importance. I have talked to Dominic over a year ago whether we can copy some of their processes here. W3C use IRC (text chat) coupled with voice conference. The chair must record a line for every important question in the chat, and there is syntax for making tasks and issues. Some bots make beautiful chat transcripts, and create tasks and issues. Maybe this describes it: http://www.w3.org/2005/Talks/02-lt-tools/, but I havent' read this presentation. I've read in detail how one of the WGs does it (maybe it was the RDF WG?) and it sounded excellent! > Probably it would also be good to have an obvious place where we record > modelling principles. I am working on writing up in a > scientific/didactic manner, but this appears also to be a major project. > Simple phrases may be helpful as reference. Agree, and the best way is a wiki. It should include Modeling principles, best practices for mapping, HOWTOs on specific topics, what Richard Light has called Linked Data Patterns... > For instance: > " ISSUE: "P43 has dimension" should apply to E1 Entity, not E70 Thing " > violates one of the most fundamental principles: > A property should have as domain the most specialized class that is > superclass of all classes for which the property can be applicable (in > the sense of potentiality). > E1 Entity is obviously the most general such class, and hence wrong. > We could, for instance, point to such rules in justifications of decisions ? I gave many examples of P43 applied to other than E70_Thing (e.g. Group: number of members, Activity: speed of driving a car, Event: number or victims of a disaster). But the important point is that there is a Range discrepancy: P39 can measure other than Things, but P43 cannot record these dimensions. Your reasoning applies equally to P39 right? So how come Issue 156 generalized P39 without generalizing P43? If we had better issue tracking, we wouldn’t have to rehash the same arguments over and over again. Cheers! Vladimir
