Mailing-List: contact ctakes-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ctakes-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 Pei.Chen@childrens.harvard.edu designates 134.174.20.73 as permitted sender)
From: "Chen, Pei" <Pei.Chen@childrens.harvard.edu>
To: "ctakes-dev@incubator.apache.org" <ctakes-dev@incubator.apache.org>
Subject: RE: First documentation pages
Thread-Topic: First documentation pages
Thread-Index: Ac28W16b/a+G+X5zRrCUbTZcQuKybAADvb7AAGgJhbAAEwZsUA==
Date: Fri, 9 Nov 2012 08:48:53 +0000
Message-ID: <924DE05C19409B438EB81DE683A942D9223D8E@CHEXMBX1A.CHBOSTON.ORG>
References: 
 <B1D5DE3F00E17F458CC1B5158EA798B3027216@MSGPEXCEI10A.mfad.mfroot.org>
 <924DE05C19409B438EB81DE683A942D9222C87@CHEXMBX1A.CHBOSTON.ORG>
 <B1D5DE3F00E17F458CC1B5158EA798B3028A6C@MSGPEXCEI10A.mfad.mfroot.org>
In-Reply-To: 
 <B1D5DE3F00E17F458CC1B5158EA798B3028A6C@MSGPEXCEI10A.mfad.mfroot.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I would suggest whatever would be easier for the person to update and maint=
ain... I presume the former?

> -----Original Message-----
> From: Bleeker, Troy C. [mailto:Bleeker.Troy@mayo.edu]
> Sent: Thursday, November 08, 2012 6:45 PM
> To: ctakes-dev@incubator.apache.org
> Subject: RE: First documentation pages
>=20
> Do we need to separate cTAKES documentation versions from one another?
> For example, if we tried to build the doc, should the files all be contai=
ned
> within one top level folder or is it OK to simply use file names as disti=
nction
> and let them all be in the same folder. I would guess the former but woul=
d
> like some guidance.
>=20
> Thanks
> Troy
> -----Original Message-----
> From: ctakes-dev-return-818-
> Bleeker.Troy=3Dmayo.edu@incubator.apache.org [mailto:ctakes-dev-return-
> 818-Bleeker.Troy=3Dmayo.edu@incubator.apache.org] On Behalf Of Chen, Pei
> Sent: Tuesday, November 06, 2012 4:15 PM
> To: ctakes-dev@incubator.apache.org
> Subject: RE: First documentation pages
>=20
>  > *         Move Getting Started under GENERAL, so it appeals to everyon=
e
> who
> > first sees the site. It will define our users and point them in the
> > right direction.
> I think the Getting Started section should be extremely simple- something
> like:
> (I think the component diagram/dependency tree should be in the manual or
> reference appendix rather than "quick" start guide).
>=20
> Requirements
> -----------
> Java 1.6+ is required to run cTAKES
>=20
> Download
> -----------
> [Link to the latest download section to apache-ctakes-{release}.tar.gz/.z=
ip]
> and unzip file.
>=20
> Running the default pipeline in the UIMA CAS Visual Debugger or Collectio=
n
> Processing Engine
> -----------
> Run bin/runctakesCVD/CPE.sh.bat
> Load AE (analysis engine)
> Select desc/ctakes-clinical-
> pipeline/desc/analysis_engine/AggregatePlaintextProcessor
> Enter note(s) and run analysis engine.
>=20
> Notes
> -----------
> If you plan to use the UMLS Resources, on can add the umls user info:
> Export/set ctakes.umlsuser=3D[username]
> Export/set ctakes.umlspw=3D[password]
> or add the system properties to the java args -Dctakes.umlsuser=3D[userna=
me]
> -Dctakes.umlspw=3D[password]
>=20
> > Now a question as well. When we went from cTAKES 1.0 to 1.2 we settled
> > on calling the parts of cTAKES one can take advantage of "component"
> > as evidenced by the diagram created and the documentation section
> > headers, etc. In the past month I've seen more people refer to the
> > cTAKES parts as "module". I'm not stuck on a name. Perhaps module is
> > more of a maven term and we didn't have that before. I have in mind
> > what I like, but as I said it does not really matter to me, so long as
> > we are consistent. If we change away from "component" the doc we pull
> > over from previous releases will need to be modified, also not too big =
a
> deal. What do you think?
>=20
> If we had references to 'component' in the previous documentation, my
> vote would be to also keep it as component; introducing a new term would
> probably just add more confusion to users.
>=20
> --Pei