+1 on waiting for the new distribution platform (and continuing to search for a
primary Release Manager).
On 3/8/23, 06:29, "Finan, Sean" wrote:
External Email
Hi all Apache cTAKES developers and users,
I have news on the release front ...
The Apache Infrastructure team is working on a new Ar
I would be in favor of using GitHub issues but only if that means we migrate
all the Jira issues there and close down Jira. Having two different issue
trackers sound like a recipe for things getting lost.
Steve
On 1/2/23, 12:02, "gandhi rajan" wrote:
External Email
Hi Sean,
Most of the GitHu
Sean, aren't you subscribed to
notificati...@ctakes.apache.org? I've been getting failed test messages
from the official cTakes build for weeks now. You've even been CC'd on some
of them. Maybe check your junk mail? I haven't said anything about these
emails because 1) I assumed everyone else was g
On Thu, Jun 22, 2017 at 9:04 AM Finan, Sean <
sean.fi...@childrens.harvard.edu> wrote:
> There is some suboptimal looping in AssertioncCleartkAnalysisEngine. For
> instance:
> Collection entities =
> JCasUtil.select(identifiedAnnotationView, IdentifiedAnnotation.class);
> for (IdentifiedA
On Thu, May 14, 2015 at 1:56 PM, Kim Ebert
wrote:
> I've done some investigation into using / working with the git repo for
> cTAKES, and I found that it is a huge. It doesn't work well with GitHub
> either, as I keep running into timeouts.
>
> I would like to make the suggest that we remove two
Yes, I ping this issue every couple months, but no luck so far. (They
take a look each time I ask, but haven't yet pushed a working git
mirror for us.)
Steve
On Tue, May 5, 2015 at 12:09 PM, Kim Ebert
wrote:
> Ah, looks like the issue is still being looked into.
>
> https://issues.apache.org/jir
>> single Element with all the mentions that were (will be) merged to create
>> that Element.
>>
>> -- James
>>
>>
>> From: Steven Bethard [steven.beth...@gmail.com]
>> Sent: Tuesday, February 10, 2015 10:59 AM
>> To: dev@ctakes.apache.org
&g
On Tue, Feb 10, 2015 at 6:36 AM, Miller, Timothy
wrote:
> Any votes for one or more of the following:
>
> A) Generalize BinaryTextRelation
> B) Create ElementMentionRelation (and then map coref chains to Elements)
I'd be okay with this one. Though Please just make the arguments
Element and Identi
nd of week then I ( or
> you, if you like) will ping infra. I know that at least one contributor (not
> me) prefers to use git.
>
>
>
> Sean
>
>
>
> -Original Message-
>
> From: Steven Bethard [mailto:steven.beth...@gmail.com]
>
> Sent: Tuesday,
The git mirrors for cTAKES seem to be either broken
(http://git.apache.org/ctakes.git) or embarrassingly out of sync
(https://github.com/apache/ctakes). Is this a known issue? I looked at
the INFRA ticket [1], but didn't see anything that suggested that
there should be a problem.
Steve
[1] https:
rove4j in ytex?
> ctakes-ytex/pom.xml
>
> --Pei
>
>> -Original Message-
>> From: Steven Bethard [mailto:steven.beth...@gmail.com]
>> Sent: Wednesday, October 15, 2014 10:40 AM
>> To: dev@ctakes.apache.org
>> Subject: YTEX depends on trove4j? LGPL issue
&
ed but
> somehow this may have been missed.
> I noticed it's in the convenience binary distro as well. We need to remove
> this; I'll create a Jira.
> VJ, could you confirm- I actually don't think we use trove4j in ytex?
> ctakes-ytex/pom.xml
>
> --Pei
>
It seems that YTEX depends on trove4j which is LGPL [1], but
"LGPL-licensed works must not be included in Apache products" [2].
Have the YTEX dependencies been reviewed for licensing issues? (I only
stumbled upon the trove issue via a version conflict in other code.)
Steve
[1] http://trove4j.sour
On Mon, Oct 6, 2014 at 3:59 PM, Bruce Tietjen
wrote:
> Since I started working with cTakes some time ago, I have found it
> difficult to compare the output between subsequent runs on the same files
> because annotations are often assigned different IDs, are listed in
> different order, etc.
At on
On Sat, Aug 2, 2014 at 7:43 AM, Miller, Timothy
wrote:
> PE: Lymphnodes: neck and axilla without adenopathy Lungs: normal and clear to
> auscultation CV: regular rate and rhythm without murmur or gallop , S1, S2
> normal, no murmur, click, rub or gal*, chest is clear without rales or
> wheezing
On Wed, Jun 25, 2014 at 3:23 PM, Chen, Pei
wrote:
> Is there an easy way to get the confidence from the classifiers from clearTK?
> Example-
> BIOChunking.createChunks(timexCas, tokens, outcomes);
If you're in a CleartkAnnotator, you can use this.classifier.score
instead of this.classifier.classi
On Mon, Jun 2, 2014 at 2:41 PM, Pei Chen wrote:
> Steve and Co.,
> Do you know if the ClearTK 2.0 upgrade will require retraining of all of
> the models?
Very likely, as the changes in package names mean that old classifiers
will probably not deserialize. Yet another reason we probably
shouldn't
On Sun, May 11, 2014 at 8:47 AM, Anirban Chakraborti
wrote:
> Steven,
>
> Would you have any example code of tree parser so the output can be
> arranged as per need. I mean, after successful annotation, I want to
> extract certain concepts like medication only and arrange them in a new
> tree so t
I don't think "not something anyone would want extracted" should be an
argument against anything. We already have constituent and dependency
parse trees in the type system, and those would fall under that
category.
So +1 on markables in the type system. (In general, +1 on moving
module-specific ty
+1. And note that once you have a descriptor, you can generate the
XML, so we should arrange to replace the current XML descriptors with
ones generated automatically from the uimaFIT code. That should reduce
some synchronization problems when the Java code was changed but the
XML descriptor was not
On Wed, Jan 29, 2014 at 5:24 AM, andy mcmurry wrote:
> Clojure, having its origins in LISP, is a better fit for serious NLP work
> than Groovy
Sorry, I have to call this one out. I don't think having origins in
LISP makes anything a better fit for serious NLP work. Not that I'm
against Clojure o
On Fri, Dec 13, 2013 at 10:32 AM, Masanz, James J.
wrote:
> The bigger issue is the following
> I was getting an error about scala, so I added the following to the Grapes
> annotation in my groovy script
> @Grab(group='org.scala-lang', module='scala-library', version='2.9.0'),
> @Grab(group='org.
We (ClearTK) talked with Richard (DKPro) about doing this for ClearTK
and DKPro. Basically, both groups were all for it, but the main issue
was time. Basically you need to:
(1) Have someone inspect the various type systems closely and make a proposal
(2) Agree on the proposal.
(3) Spend the time t
On Fri, Aug 30, 2013 at 8:46 AM, Dmitriy Dligach
wrote:
> Retraining the relation extractor should be fairly easy. The instructions I
> am about to give you apply if you are using cTAKES 3.0. However, if you are
> planning to use the trunk version, my instructions may no longer be
> accurate. Rela
On Thu, Aug 29, 2013 at 11:02 AM, Dmitriy Dligach
wrote:
> My personal opinion is we should *not* include it. It's not quite ready for
> ctakes end users just yet.
Yeah, there aren't any models included in it at the moment, so it's
not very useful.
Steve
>
> Dima
>
>
> On 08/29/2013 12:00 PM, M
was no relation), then I think the CEM
>>template filler can just not create the relation.
>>For the extremely rare cases where they need to differentiate the null vs
>>explicit negated case, they can still iterate though the
>>BinaryTextRelations because we didn't lo
On Fri, Aug 16, 2013 at 8:29 PM, Pei Chen wrote:
> Hi James/Steven,
> In the common type system/template fillers, do you recall why we stored the
> TextRelation instead of the resolved annotation?
>
> For example, in SignSymptomMention, getBodyLocation() returns
> LocationOfTextRelation.
> So in o
) @ line 99, column 15
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
>
>
>
>
unique: org.apache.ctakes:ctakes-ne-contexts:jar -> duplicate
> declaration of version (?) @ line 99, column 15
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, fu
, clean & rebuild,
> refreshes, etcs multiple times in eclipse.
>
> I don¹t think it's a general problem because I have other environments
> doing just fine, and Jenkins is not showing problems.
>
> Thanks!
>
> stephen
>
>
> On 7/30/13 6:38 PM, "St
On 30 Jul2013, at 7:32 , "Wu, Stephen T., Ph.D." wrote:
> Is anyone else getting errors importing from cleartk? In one of my
> environments, the following projects:
> ctakes-assertion
> ctakes-relation-extractor
> ctakes-temporal
> are complaining about not finding these classes
> - org.clea
Here's that error again:
On 22 Jul2013, at 12:05 , Apache Jenkins Server
wrote:
> [ERROR] 'dependencies.dependency.version' for net.sf.mastif:mastif-zoner:jar
> is missing. @ line 36, column 15
Could whoever is taking care of "ctakes-assertion-zoner" fix this? We haven't
had a successful buil
Perhaps everyone is already aware of this, but just in case, I'm seeing build
failures and have been for a while now:
$ mvn clean compile
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project org.apache.ctakes:ctakes-assertion-zone
On 17 Jul2013, at 15:52 , "Chen, Pei" wrote:
> Having a general Util to compare CAS feature structures would be so useful on
> so many levels.
> Could we create a Jira for this so that it will help facilitate dev awareness
> of these utilities when we generate release notes?
> I've been looking
; to post.
>
> -- James
>
> -Original Message-
> From: dev-return-1704-Masanz.James=mayo@ctakes.apache.org
> [mailto:dev-return-1704-Masanz.James=mayo@ctakes.apache.org] On Behalf Of
> Steven Bethard
> Sent: Wednesday, June 26, 2013 10:35 AM
> To: dev@ctakes.a
t;> Anyone know enough about assertion code to make an educated guess of whether
>> the "upgrade ClearTK dependency to 1.4.0" could be done by then too?
>>
>> -Original Message-
>> From: dev-return-1652-Masanz.James=mayo@ctakes.apache.org
>> [ma
it will have to be
declared explicitly.)
I think that sound about like what we want, right?
Steve
>
>
>> -Original Message-
>> From: Steven Bethard [mailto:steven.beth...@colorado.edu]
>> Sent: Thursday, May 09, 2013 2:46 AM
>> To: dev@ctakes.apache
As a result of the CTAKES-190 changes to the dictionary lookup [1], the
relation extractor needs some refactoring and retraining. Probably we won't
have a chance to get to that until after NAACL (June 9-15). So it would be best
for us to target the 3.1 release towards the end of June.
Steve
[1
ctakes.apache.org
> [mailto:dev-return-1646-Masanz.James=mayo@ctakes.apache.org] On Behalf Of
> Steven Bethard
> Sent: Thursday, May 30, 2013 5:45 PM
> To: ctakes-...@incubator.apache.org
> Subject: upgrade ClearTK dependency to 1.4.0?
>
> I just released ClearTK 1.4.0
I just released ClearTK 1.4.0 and there are a couple of reasons we should
probably consider updating the cTAKES dependency:
(1) ClearTK 1.4.0 can now load trained models from the classpath, so we could
get rid of the workaround
org.apache.ctakes.relationextractor.ae.RelationExtractorAnnotator.a
-
> From: dev-return-1630-Masanz.James=mayo@ctakes.apache.org
> [mailto:dev-return-1630-Masanz.James=mayo....@ctakes.apache.org] On Behalf Of
> Steven Bethard
> Sent: Friday, May 24, 2013 12:55 PM
> To: ctakes-...@incubator.apache.org
> Subject: commit messages => JIRA
&
We should consider asking infrastructure to enable this:
http://www.apache.org/dev/svngit2jira.html
Basically, it would mean that if you mention a JIRA issue in a commit, a link
to that commit is automatically added to the ticket. This is really nice for
seeing exactly where and how things get
ginal Message-----
> From: Steven Bethard [mailto:steven.beth...@colorado.edu]
> Sent: Tuesday, May 21, 2013 12:07 PM
> To: dev@ctakes.apache.org
> Subject: Re: sentence detector newline behavior
>
> On May 21, 2013, at 9:53 AM, "Savova, Guergana"
> wrote:
>&
If it's trained on clinical data, why does it need a hard rule for that? Why
isn't the model able to learn when to break on a newline or not?
Steve
> --Guergana
>
> -----Original Message-
> From: Steven Bethard [mailto:steven.beth...@colorado.edu]
> Se
On May 21, 2013, at 9:02 AM, Tim Miller
wrote:
> I think the whole reason to use a machine learning approach for sentence
> detection should be to help weigh evidence with these cases where hard
> rules cause problems, mainly 1) when a period does not end a sentence,
> but also 2) where a newl
On May 21, 2013, at 6:07 AM, "Miller, Timothy"
wrote:
> The sentence detector always ends a sentence where there are newlines.
> This is a problem for some notes (e.g. MIMIC radiology notes) where a
> line can wrap in the middle of a sentence at specified character
> offsets. In the comments for
SVM
(http://www.csie.ntu.edu.tw/~cjlin/libsvm/). It's basically
: : ...
Steve
> On Mon, May 20, 2013 at 5:54 PM, Steven Bethard > wrote:
>
>> On May 17, 2013, at 2:29 PM, giri vara prasad nambari <
>> girinamb...@gmail.com> wrote:
>>> Can someone please
On May 17, 2013, at 2:29 PM, giri vara prasad nambari
wrote:
> Can someone please clarify the difference between training-data.libsvm and
> model.libsvm in ctakes-relation-extractor module?
Where are you seeing these? Neither should be in the repository.
That said, training-data.libsvm is the L
ren't the *-res dependencies backwards?
>>
>> Steve,
>> I think that would make sense... should be fairly straightforward and
>> transparent change. I can take a closer look next week with a clear mind.
>>
>> From: Ste
On Apr 11, 2013, at 8:05 AM, "Masanz, James J." wrote:
>
> And ctakes-drug-ner-res is listed within the Maven Dependencies for
> ctakes-drug-ner
Shouldn't it be exactly the opposite of this? Shouldn't ctakes-drug-ner-res
depend on ctakes-drug-ner? Otherwise, Maven's always going to pull in
ct
On Apr 8, 2013, at 10:15 AM, "Chen, Pei" wrote:
> While working on the Dependency Parser/SRL labeler, we also have a POSTagger
> from ClearNLP. It is fairly simple and I have the code ready (also trained
> on the same data as the dep parser- MiPaq/SHARP) to be checked-in. What does
> the fol
On Apr 5, 2013, at 9:26 AM, "Chen, Pei" wrote:
> I am planning to update the existing ctakes-dependency-parser ClearParser
> (which is no longer supported) implementation with Jinho's new ClearNLP
> parser and SRL. The models have been retrained with more data (MiPaq and
> SHARP) and much impro
Excellent. Thanks for following through with this Tim!
Steve
On Mar 29, 2013, at 8:46 AM, Tim Miller
wrote:
> I emailed the author of svmlight and he was very clear that our usage is
> acceptable:
>
>Hi Tim,
>
>Using the models trained with my software in the way you describe is fi
ed but also for cases of
>>> wanting to check out a fresh copy of the code and not wanting to wait
>>> to check out the models again
>>>
>>> -- James
>>>
>>>
>>>> -Original Message-
>>>> From:
>>>> ct
54 matches
Mail list logo
