We Keep Coding

knowing ontology concepts from owl files

I have downloaded a load of owl files. I want to know what are the concepts defined in these files and then want to annotate other text based off these concepts. How would this be done? Code in Java would be good. I am a beginner. Thanks in advance

You need to use either OWL API, mainly for parsing OWL, or Apache Jena, mainly for RDF. Depending on what you want to do, they have great tutorials with sample code. If you have any specific question after you have read these, post a detailed question with the error message.

Writing and reading from an XML file with Slick2D

I was wondering how you would go about writing and the reading from an .XML file using the Java library Slick2D.
I have googled for the last couple of days and have found nothing succinct and simple that explains what I'm looking for.
I am looking for 3 things:
How to create an .XML file (would be awesome to be able to search a directory to see if there is an existing file and only create a new file if one does not already exist.
How to write to the created .XML file.
How to read from the found .XML file.
The reason for this is that I'm trying to create a save/load class for a game.
Just a general snippet of code, that I'd be able to modify for my needs would be great even for a learning experience.
So now for my question, does anyone have any information that may help me on my quest to succeed in my above stated three goals?

For checking if a file exists you can use the exists() method of java.io.File. See this for more information.
I don't know if slick2d provides it own xml utilities but you should always be able to use the standard java ways of reading/writing xml. You can use the DocumentBuilder like shown in this tutorial or a sax parser like described here. If you need to work with complex xml structures it might be worth to look into jaxb.

creating a .xml file from .xsd with java

I'm a quite new to java world and I have a requirement of generating an .xml file from an .xsd file
I did some research and found that 'jaxb' could do it. And I found some example too, but the problem is, almost all the examples uses 'xjc' tool to do this. But I want a way to do this through my java code.
Os this possible?
if yes, I'm thinking something like this, from my java code
load the .xsd file
generate the .xml
save the .xml file
Can someone direct me to a good resource and or tell me if my thinking is wrong

I've had good experiences using XMLBeans, however I've always had the XSD available at compile time. It integrates nicely with Maven (plus potentially other build systems). The compilation produces a series of Java classes that can be used to construct an XML document that conforms to the XSD or process an XML file you've received.
You can potentially do some runtime processing of an XSD using the org.apache.xmlbeans.XmlBeans.compileXsd class, but I've never experimented with it. Just seen a reference from an FAQ.

I think the main problem is that to do it in a clean way you should have classes reflecting your xsd. Xsd defines a data model, so the important part is to recreate it with classes. If you want to do it dynamically it could be rather difficult. If you want to do it at compile time- jaxb is the way to go. There is very interesting article talking about problems related with parsing xml (it goes from a different perspective than you describe), but I think there is a wealth of knowledge to be learned from here:
http://elegantcode.com/2010/08/07/dont-parse-that-xml/

quartz: documentation for xml files?

Where is the documentation for quartz xml files (specifically jobs.xml)? I found the javadoc online, but I can't seem to find the documentation for how to write an xml file, just some brief examples e.g. this one from O'Reilly.
edit: apparently the java class that reads the jobs.xml is JobInitializationPlugin, but I don't see the docs for the xml format there either.

This is really poorly documented. Beyond the brief mention at the OpenSymphony site, the only documentation comes in the form of a Document Type Definition (DTD) and an XML Schema. If you're familiar with these formats, you can use them to figure out what tags are available.
If you download the full Quartz distribution, they are located at /quartz/src/main/resources/org/quartz/xml/. You can also find them inside of quartz-1.7.3.jar at /org/quartz/xml/. The files are named job_scheduling_data_1_5.dtd and job_scheduling_data_1_5.xsd.

Best XML format for log events in terms of tool support for data mining and visualization?

We want to be able to create log files from our Java application which is suited for later processing by tools to help investigate bugs and gather performance statistics.
Currently we use the traditional "log stuff which may or may not be flattened into text form and appended to a log file", but this works the best for small amounts of information read by a human.
After careful consideration the best bet has been to store the log events as XML snippets in text files (which is then treated like any other log file), and then download them to the machine with the appropriate tool for post processing.
I'd like to use as widely supported an XML format as possible, and right now I am in the "research-then-make-decision" phase. I'd appreciate any help both in terms of XML format and tools and I'd be happy to write glue code to get what I need.
What I've found so far:
log4j XML format: Supported by chainsaw and Vigilog.
Lilith XML format: Supported by Lilith
Uninvestigated tools:
Microsoft Log Parser: Apparently supports XML.
OS X log viewer:
plus there is a lot of tools on http://www.loganalysis.org/sections/parsing/generic-log-parsers/
Any suggestions?

Unfortunately, I can't give you the answer you are looking for, but I would like to warn you of something to consider when logging to XML. For example:
<log>
<msg level="info">I'm a log message</msg>
<msg level="info">I'm another message</msg>
<!-- maybe you won't even get here -->
<msg level="fatal">My server just ate a flaming death
In the above snippet of a potential XML log you can see the biggest drawback of logging to XML. When a catastrophic failure happens, your log format becomes broken because it requires closing tags. However, if you are using a program that parses your primary log output, this shouldn't be too much of a problem.

If you are defining your own XML log file writing, you do not need to worry about having a closing and opening tag in order to produce valid XML. Elijah's answer is right in that you do have the issue if you want to create an XML document, but that is not necessary straight off. The W3 standard also defines XML Entities (see section 4.3 of the W3's XML 1.0 spec, second edition, which unfortunately I cannot link to for you because I do not have enough points), which would be more suitable for log-style continual appending to a file without rewriting parts of it. You can then create a referencing XML wrapper document if you need to work with an actual XML document rather than an XML entity (see http://www.perlmonks.org/?node_id=217788#217797 for an example)

One of the nice things in log4j is that it offers nice possibilities for customizing the log formats and where those are written to.
So instead of choosing some log file format, I'd choose some logging library that allows to change the format and allows also getting the log directly to some program.

I'd advise you consider logback-access for events.
Other than that, anything using JMX, as it was made to match the feature set of SNMP.

It appears that the Lilith log viewer contains an XML-format which is well suited for dealing with the extra facilities available in logback and not only the log4j things.
It is - for now - the best bet so far :)
I adapted the log4j xmllayout class to logback, which works with chainsaw.
As I have not been able to find a suitable log viewer capable of visualizing event information (instead of just presenting all events in a table) I have for now decided to create a very terse xml layout containing machine parsable information based on the above which can then be postprocessed by the Microsoft LogParser to any format I need.