Details of the project I described are no longer available on the web, but they can be explored here:
https://web.archive.org/web/19961221214555/http://www.funderfinder.org.uk/ On Monday, 17 July 2017, 11:44, Richard Haselgrove <[email protected]> wrote: That intervention has prompted me to look more closely at the 'Job and Project Keywords' design document. It reminds me very much of a project I was involved in between 1990 and about 2005. I was the sole coder on the team, but the philosophy and design were led by a project leader above me. Our project was called 'FunderFinder', and was intended to help UK community groups raise funds from UK charitable trusts, some of which had trust deeds dating back to the seventeenth century - so the terminology was arcane, to say the least. Our matching had to be more precise, so we did develop a 'complete taxonomy of charity funding' (with the help of a cataloguing expert from the British Library), but in general terms our solution was very similar to yours. I would identify two differences - the first trivial, the second perhaps significant. We used a three-way classification: People, Subjects, Places - that enabled us to distinguish between, for example, medical research into cancer (a subject), and the care of patients with cancer (people). More importantly, instead of your integer to represent a keyword, we used an alphanumeric code: to keep the structure clear in our own minds, we used lower case letters for people, upper case letters for subjects, and numerals for places. I can't match your examples exactly, but we had H Medicine and HealthHM Diseases and disordersHMW Tumours (including cancer)HMWC CancerHMWL LeukaemiaHMWM Melanoma and for the patients, jdgwc Cancer We found that seven-character codes were sufficient to cover the worst case, from 2 (UK) / 5 (rest of the world) down to a single historic parish council via the modern local government administrative structure. The advantage of using a hierarchical coding was that I could use sub-string pattern matching to include and exclude higher or lower level matches. That's probably overkill for the current proposal, but it seems to be a shame to design out the possibility of a hierarchical search at this stage. On Monday, 17 July 2017, 9:04, Christian Beer <[email protected]> wrote: I just want to voice my disagreement with the process in which this proposal was handled. There was barely time to comment and so far no one did but implementation into the master branch has already started for what seems to be a major change to Client and Server code. As a volunteer contributor and committer to BOINC and as a BOINC PMC member this proposal and the process in which it is done does not have my approval. Regards Christian P.S.: Although this mail is sent from my AEI email the opinion expressed above is my personal one. On 14.07.2017 01:04, David Anderson wrote: > I propose adding a mechanism for associating keyword attributes > (such as science area) with jobs and projects. > https://boinc.berkeley.edu/trac/wiki/DesignKeywords > Comments welcome. > -- David > _______________________________________________ > boinc_projects mailing list > [email protected] > https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_projects mailing list [email protected] https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
