GATE usage in java Netbeans - java

I am trying to write an application from extracting entities from a text and want to use GATE jar files. For which I have installed the GATE tool and have imported jar files, but it is giving errors. I can't understand from where to download more jar files and how to run the first simple program with this.

Please make sure that you added gate.jar from YOUR_GATE_HOME/bin folder.

From your screenshot I can assume that you used an example provided by GitHub. This example looks good, except one part (from my point of view of course). I would suggest to replace output piece with the next more readable code:
String text = "Steve works for Apple Inc in California.";
Document gateDocument = Factory.newDocument(text);
corpus.add(gateDocument);
// tell the ANNIE application about the corpus and run it
annie.setCorpus(corpus);
annie.execute();
List<Annotation> personAnnotations = gateDocument.getAnnotations().get(ANNIEConstants.PERSON_ANNOTATION_TYPE).inDocumentOrder();
for (Annotation personAnnotation : personAnnotations) {
System.out.println("Entity Text: " + gate.Utils.stringFor(gateDocument, personAnnotation) + " Features: " + personAnnotation.getFeatures());
}
Similar things could be done for Location, Organisation and other Entity types defined in GATE. Also do not forget to release resources with Factory.deleteResource().

Related

Netlogo Api Controller - Get Table View

I am using Netlogo Api Controller With spring boot
this my code (i got it from this link )
HeadlessWorkspace workspace = HeadlessWorkspace.newInstance();
try {
workspace.open("models/Residential_Solar_PV_Adoption.nlogo",true);
workspace.command("set number-of-residences 900");
workspace.command("set %-similar-wanted 7");
workspace.command("set count-years-simulated 14");
workspace.command("set number-of-residences 500");
workspace.command("set carbon-tax 13.7");
workspace.command("setup");
workspace.command("repeat 10 [ go ]");
workspace.command("reset-ticks");
workspace.dispose();
workspace.dispose();
}
catch(Exception ex) {
ex.printStackTrace();
}
i got this result in the console:
But I want to get the table view and save to database. Which command can I use to get the table view ?
Table view:
any help please ?
If you can clarify why you're trying to generate the data this way, I or others might be able to give better advice.
There is no single NetLogo command or NetLogo API method to generate that table, you have to use BehaviorSpace to get it. Here are some options, listed in rough order of simplest to hardest.
Option 1
If possible, I'd recommend just running BehaviorSpace experiments from the command line to generate your table. This will get you exactly the same output you're looking for. You can find information on how to do that in the NetLogo manual's BehaviorSpace guide. If necessary, you can run NetLogo headless from the command line from within a Java program, just look for resources on calling out to external programs from Java, maybe with ProcessBuilder.
If you're running from within Java in order to setup and change the parameters of your BehaviorSpace experiments in a way that you cannot do from within the program, you could instead generate experiment XML files in Java to pass to NetLogo at the command line. See the docs on the XML format.
Option 2
You can recreate the contents of the table using the CSV extension in your model and adding a few more commands to generate the data. This will not create the exact same table, but it will get your data output in a computer and human readable format.
In pure NetLogo code, you'd want something like the below. Note that you can control more of the behavior (like file names or the desired variables) by running other pre-experiment commands before running setup or go in your Java code. You could also run the CSV-specific file code from Java using the controlling API and leave the model unchanged, but you'll need to write your own NetLogo code version of the csv:to-row primitive.
globals [
;; your model globals here
output-variables
]
to setup
clear-all
;;; your model setup code here
file-open "my-output.csv"
; the given variables should be valid reporters for the NetLogo model
set output-variables [ "ticks" "current-price" "number-of-residences" "count-years-simulated" "solar-PV-cost" "%-lows" "k" ]
file-print csv:to-row output-variables
reset-ticks
end
to go
;;; the rest of your model code here
file-print csv:to-row map [ v -> runresult v ] output-variables
file-flush
tick
end
Option 3
If you really need to reproduce the BehaviorSpace table export exactly, you can try to run a BehaviorSpace experiment directly from Java. The table is generated by this code but as you can see it's tied in with the LabProtocol class, meaning you'll have to setup and run your model through BehaviorSpace instead of just step-by-step using a workspace as you've done in your sample code.
A good example of this might be the Main.scala object, which extracts some experiment settings from the expected command-line arguments, and then uses them with the lab.run() method to run the BehaviorSpace experiment and generate the output. That's Scala code and not Java, but hopefully it isn't too hard to translate. You'd similarly have to setup an org.nlogo.nvm.LabInterface.Settings instance and pass that off to a HeadlessWorkspace.newLab.run() to get things going.

Google Cloud Dataflow: Submitted job is executing but using old code

I'm writing a Dataflow pipeline that should do 3 things:
Reading .csv files from GCP Storage
Parsing the data to BigQuery campatible TableRows
Writing the data to a BigQuery table
Up until now this all worked like a charm. And it still does, but when I change the source and destination variables nothing changes. The job that actually runs is an old one, not the recently changed (and committed) code. Somehow when I run the code from Eclipse using the BlockingDataflowPipelineRunner the code itself is not uploaded but an older version is used.
Normally nothing wrong with the code but to be as complete as possible:
public class BatchPipeline {
String source = "gs://sourcebucket/*.csv";
String destination = "projectID:datasetID.testing1";
//Creation of the pipeline with default arguments
Pipeline p = Pipeline.create(PipelineOptionsFactory.fromArgs(args).withValidation().create());
PCollection<String> line = p.apply(TextIO.Read.named("ReadFromCloudStorage")
.from(source));
#SuppressWarnings("serial")
PCollection<TableRow> tablerows = line.apply(ParDo.named("ParsingCSVLines").of(new DoFn<String, TableRow>(){
#Override
public void processElement(ProcessContext c){
//processing code goes here
}
}));
//Defining the BigQuery table scheme
List<TableFieldSchema> fields = new ArrayList<>();
fields.add(new TableFieldSchema().setName("datetime").setType("TIMESTAMP").setMode("REQUIRED"));
fields.add(new TableFieldSchema().setName("consumption").setType("FLOAT").setMode("REQUIRED"));
fields.add(new TableFieldSchema().setName("meterID").setType("STRING").setMode("REQUIRED"));
TableSchema schema = new TableSchema().setFields(fields);
String table = destination;
tablerows.apply(BigQueryIO.Write
.named("BigQueryWrite")
.to(table)
.withSchema(schema)
.withWriteDisposition(BigQueryIO.Write.WriteDisposition.WRITE_APPEND)
.withCreateDisposition(BigQueryIO.Write.CreateDisposition.CREATE_IF_NEEDED)
.withoutValidation());
//Runs the pipeline
p.run();
}
This problem arose because I've just changed laptops and had to reconfigure everything. I'm working on a clean Ubuntu 16.04 LTS OS with all the dependencies for GCP development installed (normally). Normally everything is configured quite well since I'm able to start a job (which shouldn't be possible if my config is erred, right?). I'm using Eclipse Neon btw.
So where could the problem lie? It seems to me that there is a problem uploading the code, but I've made sure that my cloud git repo is up-to-date and the staging bucket has been cleaned up ...
**** UPDATE ****
I never found what was exactly going wrong but when I checked out the creation dates of the files in my deployed jar, I indeed saw that they were never really updated. The jar file itself had however a recent timestamp which made me overlook that problem completely (rookie mistake).
I eventually got it all working again by simply creating a new Dataflow project in Eclipse and copying my .java files from the broken project into the new one. Everything worked like a charm from then on.
Once you submit a Dataflow job, you can check which artifacts were part of the job specification by inspecting the files that are part of the job description which is available via DataflowPipelineWorkerPoolOptions#getFilesToStage. The code snippet below gives a little sample of how to get this information.
PipelineOptions myOptions = ...
myOptions.setRunner(DataflowPipelineRunner.class);
Pipeline p = Pipeline.create(myOptions);
// Build up your pipeline and run it.
p.apply(...)
p.run();
// At this point in time, the files which were staged by the
// DataflowPipelineRunner will have been populated into the
// DataflowPipelineWorkerPoolOptions#getFilesToStage
List<String> stagedFiles = myOptions.as(DataflowPipelineWorkerPoolOptions.class).getFilesToStage();
for (String stagedFile : stagedFiles) {
System.out.println(stagedFile);
}
The above code should print out something like:
/my/path/to/file/dataflow.jar
/another/path/to/file/myapplication.jar
/a/path/to/file/alibrary.jar
It is likely that the resources part of the job that your uploading are out of date in some way containing your old code. Look through all the directories and jar parts of the staging list and find all instances of BatchPipeline and verify their age. jar files can be extracted using the jar tool or any zip file reader. Alternatively use javap or any other class file inspector to validate that the BatchPipeline class file lines up with the expected changes you have made.

Eclipse RCP: InternalPlatform.getDefault().getUserLocation() doesen't return C:\Users\username\AppData\Roaming

I am currently migrating an Eclipse 3.0 application to 4.4. The user data was and still should be stored in the folder C:\Users\username\AppData\Roaming\applicationname
The application is using following code to read the directory:
public static String getUserDirectory()
{
String directory = InternalPlatform.getDefault().getUserLocation().getFile();
return directory;
}
I know the code is deprecated, but following code returns the same:
public static String getUserDirectory()
{
String directory = Platform.getUserLocation().getURL().getFile();
return directory;
}
They both return C:\Users\username\user but as I said the user data should be stored at C:\Users\username\AppData\Roaming\applicationname. Did the behaviour of those methods change?
How can I realize that I store my user data under C:\Users\username\AppData\Roaming\applicationname and my application can still find the directory?
I know this has to do something with environment-variables which I don't fully understand.
I don't have a 3.x target platform at hand to compare but C:\Users\username\user looks plain wrong.
If you are interested in the details, the constructor of EquinoxLocations computes the userLocation and adds the literal 'user' the the user's home directory if no default is specified.
Hence, if you start your application with -user #user.home or -Dosgi.user.area=#user.home, the user location will be set to C:\Users\username\. Still not what you are looking for, but at least a sane value.
I think this is a bug in Equinox and recommend to file a bugzilla. If it turns out that there is a good reason for this appraoch the bug entry will still serve as documentation/reasoning.
In the meanwhile you could obtain the home directory on Windows through System.getenv( "APPDATA" ). According to this post it will return the roaming home directory.
I solved the problem by adding three properties in the Configuration tab of my config.ini.product-file:
osgi.configuration.area =
#user.home/AppData/Roaming/ApplicationName/...
osgi.user.area =
#user.home/AppData/Roaming/ApplicationName/...
osgi.instance.area =
#user.home/AppData/Roaming/ApplicationName
Now my method as stated in my question reads the paths that are configured by those properties and the config.ini file which is generated looks exactly like the one of the old build with Eclipse 3.0.

Unable to get version name in code after moving to Gradle

I've just moved one of my Android projects over to Gradle, and as per recommendations inside the IDE and online I've moved all the configurations (min/max sdk, version name/code etc) into the build.gradle file.
Now a bug has been reported from a customer that where he could usually see the version name and code inside the product there is nothing.
After checking it out I've found out that the usual way of extracting those values has stopped working after I removed the android:versionCode="" and android:versionName="" tags from AndroidManifest.xml. I have verified that it works when these values are there.
Now I've been trying to search for a way of extracting these same values to use in code, but I have not found any reference to this behaviour else where (this not working like this).
The code I used to use to get the values was to simply extract them from the PackageManager as so
try {
PackageInfo pInfo = ctx.getPackageManager().getPackageInfo(ctx.getPackageName(), 0);
return pInfo.versionName + " Build " + pInfo.versionCode;
} catch(PackageManager.NameNotFoundException e){
e.printStackTrace();
}
All hints, tips or solutions appreciated.
Use the BuildConfig class to fetch your version code which are defined in build.gradle file:
Log.e(TAG, BuildConfig.VERSION_NAME + " Build " + BuildConfig.VERSION_CODE);

JRules ruleset path syntax explanation required

I'm using JRules 6 and trying to execute a rule using the JRules API.
I create a new IlrSessionRequest object, passing a ruleset path to its constructor. When it executes, it fails, saying Syntax error in ruleset path and an error code of XU.ERROR.10048. Google isn't providing much help ..
What does the ruleset path refer to? Niaevely, I've just put in the path to the jar file that contains my XOM, but it doesn't seem to like that.
Any idea how I can find out what the ruleset path is?
The Path has to be specified in the same way it is shown on the Rule Execution Server:
/ruleApp/ruleSet without any path-information. Here is a sample of the usage in JRules 7.1. This may work different on JRules 6:
String rulesetPath= "/" + "your_ruleApp" + "/" + "your_ruleset";
IlrSessionFactory factory = new IlrPOJOSessionFactory();
IlrSessionRequest request = factory.createRequest();
request.setRulesetPath(rulesetPath);
XU = eXecution Unit so based on your explaination I would say that "JRules" is complaining because it cannot find your ruleset in your ruleapp and hence crashes.
Open the jar file (ruleapp) inside you should see at least one folder named: "your ruleapp name"
in it a folder named: "your ruleapp version" (possibly "1.0")
in it : "your ruleset name"
in it : "your ruleset version"
and in it your rule atrifacts.
Makes sense?
Possible ruleset path:
1/ ruleappName/ruleappVersion/rulesetName/rulesetVersion
2/ ruleappName/rulesetName/rulesetVersion
3/ ruleappName/ruleappVersion/rulesetName
4/ ruleappName/rulesetName
Note: Version is optional and if not specified then the latest version deployed will be used.
I coded a whole set oh Helpers and Factories for JRules (7.01 and 7.1) - some tweaks may be needed with version 6
Let me know if you are interested.
Basically there are RTSHelper and RESHelper libraries
containing static methods to create queries, business rules, extractor, ruleset, ruleapp, deploy, create a ruleset based on query and so on...
Remove ruleapp from RES after execution and a lot more...

Categories