[Feature]: intro and contributing to ctakes-ytex
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
Research direction
Start by reviewing the ctakes-ytex build process, its XML database-connection templates, and the MRCONSO.RRF, MRSTY.RRF, and pre-built concept graph artifacts mentioned in the issue. Compare the proposed metric corrections and additions with the Perl UMLS::Similarity outputs. Done means the work is split into separately scoped, reviewable pull requests with project guidance on the data and binary updates.
Written by the indexing model from the issue text.
Description
What problem does this solve?
I have been able to update the ctakes-ytex build process to now run with
modern versions of MySQL (using Ubuntu 23.10 and MySQL version 8.0.35)
which I would like to contribute back to the project. In addition, I
have found some computational "bugs" in a couple of the kernel metrics
in the ctakes-ytex package which I have now been able to correct and
match the outputs generated from the old Perl UMLS::Similarity package.
In addition, I've added a couple of metrics provided by the Perl module
which were not in the ctakes-ytex code (such as Resnik and Faith
algorithms).
Describe the solution you'd like
I was going to propose submitting as 3 separate pull requests:
PR-1 : update build process to support modern MySQL database
Q's - is it appopriate to update the supplied MRCONSO.RRF and MRSTY.RRF
files from UMLS with current versions? How about me updating the
pre-built concept graphs as binary .gz files?
To support the MySQL connection, there are XML templates which parse the
DB connection and I don't have an elegant way to pass through the & vs
& so I had created two separate DB properties (one for direct JDBC
connections in the ctake-ytex code that can't work with the &
escaped version and another for the XML templates to parse)
PR-2 : submit corrections to the metrics which are broken
PR-3 : submit new metrics
Please let me know if this makes sense, and how best to work with your
team. Should I fork the github repo into my own or create a new branch
and submit the PRs from there? What are the preferred ways of working
and contributing to the cTakes project?
Alternative solutions you've considered
No response
Priority
None
Contact Details
No response
- Dominant language
- Java
- Stars
- 138
- Forks
- 27
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/ctakes
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
elastic/gradle-plugins#157 ·
-
enhancement Tools
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
apache/rocketmq-dashboard#5008 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
DETECT_PARAMETER_NAMES=false silently disables @ConstructorProperties-based Creator detection too Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
FasterXML/jackson-databind#6229 ·