Richard:
Thanks for the comments.
In the current framework, keywords have "symbols" as well as integer IDs:
https://boinc.berkeley.edu/keywords.php?header=c
https://boinc.berkeley.edu/keywords.php?header=python
This makes it easy to specify them e.g. in job-submission programs.
I think it's better not to encode hierarchy into the symbols,
because we may want to change the hierarchy over time:
e.g. to move Cosmology from Astronomy to Physics,
or create new levels.
This doesn't preclude hierarchical search;
it would be based on the actual hierarchy as encoded, e.g., in
https://boinc.berkeley.edu/keywords.php
rather than on symbols.
-- David
On 7/17/2017 3:40 AM, Richard Haselgrove 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 <christian.b...@aei.mpg.de>
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
boinc_proje...@ssl.berkeley.edu
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
boinc_dev@ssl.berkeley.edu
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_dev mailing list
boinc_dev@ssl.berkeley.edu
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_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
