Categories
Photography

Shy globe of war

I tried to capture an image of Mars last night, but the fates weren’t with me and the globe seemed elusive. I could see it in the telescope but it was a dull yellow pink in color, not the vibrant rust-orange we’ve come to expect from Mars.

We’ve had no rain and St. Louis is one of the ten worst cities for air pollution though thanks to the cooler temperatures we haven’t had the problems we had last year. With the morning rain, I hoped the air would be clearer, and set the telescope up on the back deck.

I spotted Mars peeking out from behind the big tree on the corner and was turning the telescope around when bright flashes of light caught the corner of my eye. As fast as Mars was heading to the West, a storm was heading to the East. A beautiful and usual storm, too, and I was momentarily tempted to take photos of it, until I came to my senses and recalled exactly which event is the less frequent.

I have a good camera, a Nikon 995, but not a beauty like a D100 or even, in my dreams, a D1X. I have a good telescope, a Meade ETX70, but not a powerhouse like the 14″ Schmidt-Cassegrain. Added to the mix, I don’t have an attachment that will allow me to take photos through the special port on the telescope and I have to use the eye piece. This is my way of saying that my photos of Mars are properly orange, helped a bit by the haze and the 800 ISO camera setting, and I guess we’ll need to be content with that.

mars1.jpg

This photo was dead centered in the telescope. Notice that no real detail of the planet shows, including, unfortunately, the polar ice cap. No matter how I tweaked the telescope, and which lens I used, the ice cap wouldn’t come through.

I have found with the moon at least that sometimes taking a more oblique photo of the object can bring out details. I tried that with the next shot, and if nothing else, there’s more of a suggestion of roundness to the photo.

mars3.jpg

Finally, after 2 hours of taking photos and a storm quickly moving in, I managed to get the following. Now, whether the streak was something to do with my telescope, or a reflection of the major canyon system on the Red planet, I don’t know…and I don’t care. If I call it a Martian detail, it is, henceforth, a Martian detail.

Of course, Hubble photos blow away my own little attempts, but that’s not the point. The point is standing on your deck and taking a picture of another planet. All the wonderous photos from Hubble and all the major telescopes and all the detail combined won’t dim my satisfaction in these, my little orange balls of fuzz.

This photo I’ll leave for you all as I drag myself to bed after two nights up late, chasing a globe of war.

mars4.jpg

Categories
RDF

Jena Week: final examples

Recovered from the Wayback Machine.

I converted the rest of the Jena1 examples to Jena2 without any major reworking being necessary. At the end of this post is a zipped file of all of the Java source that you can download, use to start your own explorations.

In Example 7, reading in an RDF/XML file in is no different with Jena2 than it was with Jena1. The examples don’t change (other than class structure and creating the memory model using the factory object), except that iterating through statements using StmtIterator exhibits better Java behavior now. StmtIterator now returns an Object when you use next rather than a Statement, and you’ll need to cast it. Or you can use the new nextStatement function call:

// next statement in queue
Statement stmt = iter.nextStatement();

Examples 8 and 9 work against graphs/models persisted to a relational database. I used MySQL in Windows 2000 to test the examples, but you can also use Oracle or other supported database systems.

There have been some significant changes, for the better, with using a relational data model for persistence in Jena2. For instance, you don’t have to specify a storage type or preformat the storage as you did with Jena1; this is all automated in the new classes, by passing in the type of database when you create the model. Another change is that you don’t use the RDBModel.create method, which is deprecated – you can use a new class, ModelMaker, or you can call the static function, createModel.

In the following, the driver is loaded, a connection is established and a model created. Once created, a serialized RDF/XML graph is read.

// load driver class
Class.forName(“com.mysql.jdbc.Driver”).newInstance();

// establish connection – replace with your own conn info
Connection con = DriverManager.getConnection(sConn, sUser, sPass);
IDBConnection dbcon = new DBConnection(con, “MySQL”);

ModelRDB model = ModelRDB.createModel(dbcon, “one”);
model.read(sUri);

Check the documentation for Jena2, and in the DB directory, you’ll find a discussion on migrating Jena1 databases to Jena2, as well as a good description of these changes, and example code.

One interesting aspect of storing Jena within a relational database, especially as it relates to previous postings, is whether Jena2 maintains a reference to the actual source of the external data, and from what I can see, it does not.

Within Jena, you create a graph (termed a model in Jena) and can load many serialized sub-graphs (individual RDF/XML files) into it, or add statements directly using the API. I did so, loading in several FOAF files from people I know. I then looked through the data to see if the source of the sub-graph, the actual file, was maintained and couldn’t find anything.

Once the sub-graphs are merged into one graph, all blank nodes are resolved, and any traces of their separate natures are not maintained. This is proper behavior for RDF according to the RDF specifications, and this merging of sub-graphs is one of strengths of the RDF model.

Now, you can perform a little deductive work and find that a person’s properties have a specific blank node identifier, which is then the object of a “knows” predicate, which is then the property of another blank node identifier of another person with a given name – a bit of a fun challenge with RDQL – but there’s nothing I can see that identifies the source of the actual RDF/XML file, itself.

It could be among the information stored in the BLOB that makes up the graph’s name, but the only way to know this for sure is to examine the contents of BLOB itself, or to find a specific class that allows us to interrogate this data. However, that breaks into new territory not covered in the book examples, and best left for further essays.

Download file

Categories
Photography

Starry starry night

This week Mars is closer to our planet than at any other time in the last 60,000 years. In anticipation of a couple of night time field trips this week to see the ruby beauty, I spent the day yesterday with my telescope trying to figure out how to use the star/planet automatic tracking system. I can operate and maintain most types of computers, was first in my class in electronics in college, and can even program a VCR — you would think I could figure out how to program the telescope, wouldn’t you?

My mother gave me the telescope for Christmas two years ago. I’d been eying them for years, but just couldn’t bring myself to plunk down the money. I’d never told my mother I wanted a telescope — she just thought they’d make good presents, and sent one to me.

When I was in San Francisco, I used the telescope to look from my apartment out onto the harbor at the boats and the birds, and once seeing a shark attack a pelican, but I didn’t use it at night. I felt that people might misconstrue it’s use at night.

After I moved to Missouri, I’ve used it to look at and take photos of the moon, but this week is the first I’ve tried to use the automated features of the beasty, to faciliate my Mars viewing experience. Last night out on the back porch in 96+ F (in Celsius, “hot”) degree weather, I spent a happy hour training the telescope so that I can have it automatically find objects for me, and then track them once fixed. I viewed constellations and what might have been Uranus, lost in the heat haze and street light reflections. Unfortunately, light polution and a big tree blocked Mars, but tomorrow and Wednesday, I’ll move to more telescope friendly areas. To see Mars with my own eye, directly — what a wonder.

Thinking about people who love art but don’t necessarily love nature — I wonder if sometimes an artist isn’t more of a translator than anything else, interpreting the beauty of every day things for those who can’t see the beauty any other way. The artist is inspired to create art to inspire others who cannot be inspired by that which inspired the artist.

Who cannot be excited about seeing Mars directly, who cannot be moved by a night filled with stars or a full moon. Yet people will go into raptures about Vincent van Gogh’s masterpiece, Starry Night, and never spare a glance for a night sky unless its filled with neon and they have a martini in their hand.

Not van Gogh, though. I picture van Gogh, half mad, which is worse than being fully mad, pacing about at night because he can’t quiet the demons long enough to sleep. In one breathless, immortal moment, he lifts his head and looks out over the sleeping town below, and at the stars blazing in the heavens above on this crisp, cool night. In perfect clarity, he sees the glory of the stars, their truth, as they burned themselves into his soul and hence to his art, so that he may show those below him what they miss in their sleep and their sanity.

But I will refrain from falling into the trap of the inevitable by including the lyrics to Starry, Starry Night, though I do like the song. Besides, I know you’ve been humming it under your breath since you read the title.

moonshot.jpg

Categories
Photography

Waiting for prosperity

people waiting for the train silhouetted against Arch

Categories
RDF

Jena Week: Migrating the first example

Recovered from the Wayback Machine.

(Note: all examples are compiled and run on a Windows 2000 box, MySql 4.x, Java 1.4.1_01)

I downloaded and unzipped the Jena2 from the SourceForge project and first thing I noticed is that there is a lot of material with this download. With the classes for the ontology support as well as RDF, this is a large Java framework, providing support for all aspects of RDF and OWL, including an inferential engine, the ‘reasoner’.

The second thing I noticed is that the documentation for Jena2 is sketchy at best, with the tutorial still set for Jena 1.4, some migration guides, and the ubiquitous Javadocs. But hey! We all know that Java is self-documenting with Javadocs, so we don’t need to stinkin’ tutorials and user manuals. Besides, tutorials are for babies.

Seriously, the generated Java documentation, installation and migration guides, and the essential Jena Mini I/O are enough if you’ve worked with Jena previously. If not, hopefully the essays this week, migrating the Jena applications in the book to Jena2 will provide a good start in your efforts.

(If all goes well, next week we’ll work with the ontology classes and all of the other new Jena2 goodes. )

Once installed, I added all of the Jena jar files to my classpath, per the README document in the root directory. I then tested the installation using the test.bat file, but I could have used Ant, or used test.sh within a Unix environment. Once tested, second step was to start porting the first example Java application, reproduced here as a guide:

import com.hp.hpl.mesa.rdf.jena.mem.ModelMem; import com.hp.hpl.mesa.rdf.jena.model.*; import com.hp.hpl.mesa.rdf.jena.common.PropertyImpl; import java.io.PrintWriter;

public class pracRDFFirst extends Object {

public static void main (String args[]) { String sURI = “http://burningbird.net/articles/monsters1.htm”; String sPostcon = “http://www.burningbird.net/bbd/elements/1.0/”; String sRelated = “related”; try { // create an empty graph Model model = new ModelMem();

// create the resource Resource postcon = model.createResource(sURI);

// create the predicate (property) Property related = model.createProperty(sPostcon, sRelated);

// add the properties with associated values (objects) postcon.addProperty(related, “http://burningbird.net/articles/monster3.htm”); postcon.addProperty(related, “http://burningbird.net/articles/monster2.htm”);

// Print RDF/XML of model to system output model.write(new PrintWriter(System.out));

} catch (Exception e) { System.out.println(“Failed: ” + e); } } }

 

This example is pretty simple: create an in-memory model, a new resource, and add two properties to that resource, both with the predicate “related”. Absolute URIs are used, and once the model is built, it’s printed out to the system. General exceptions are captured and the error message is printed. No other error checking and management is done.

The first step in migrating this example is to change the existing class structure to the new refactored one:

    * com.hp.hpl.mesa.rdf.jena.model -> com.hp.hpl.jena.rdf.model
    * com.hp.hpl.mesa.rdf.jena.vocabulary -> com.hp.hpl.jena.vocabulary

 

This is a bit tricky at first because not only is ‘mesa’ removed, the jena.rdf reference is reversed. Another change is the fact that there no longer is a specific ModelMem class or a specific PropertyImpl implementation class. This simplifies the number of Java classes that are included:

import com.hp.hpl.jena.rdf.model.*;
import java.io.FileOutputStream;
import java.io.PrintWriter;

 

The actual code of the application doesn’t change drastically. We’re using a class factor rather than new, but creating the resource and adding the properties doesn’t change:

import com.hp.hpl.jena.rdf.model.*;
import java.io.FileOutputStream;
import java.io.PrintWriter;

 

public class pracRDFFirst extends Object {

public static void main (String args[]) { String sURI = “http://burningbird.net/articles/monsters1.htm”; String sPostcon = “http://burningbird.net/postcon/elements/1.0/”; String sRelated = “related”; try { // create an empty graph Model model = ModelFactory.createDefaultModel();

// create the resource Resource postcon = model.createResource(sURI);

// create the predicate (property) Property related = model.createProperty(sPostcon, sRelated);

// add the properties with associated values (objects) postcon.addProperty(related, “http://burningbird.net/articles/monster3.htm”); postcon.addProperty(related, “http://burningbird.net/articles/monster2.htm”);

 

Once the model is built, to print it out with Jena, I used to use Jena’s Writer. In Jena2, this is replaced with InputStream and OutputStreams, a change significant enough for the Jena team to put out wht they call a “Rush Guide – Jena 1 Migration (Must Read)”.

According to the guide:

The Jena1 developer will note that all but one of these methods are new in Jena2. Jena1 mistakenly required the use of java.io.Reader and java.io.Writer. While these classes work well on a single machine, the way they address character encoding problems differs significantly from the solution offered by XML. A typical use of the Jena1 input interface such as mdl.read(new FileReader(fName)); is incorrect, and will give the wrong results if the file contains non-ASCII data. Also, in Jena1, mdl.write(new FileWriter(fName)); wrote incorrect XML for non-ASCII data (now fixed). However, these two bugs in Jena1 canceled each other out, as long as the system doing the reading had the same default character encoding as the one doing the writing, which is why it did not bite in a typical development environment. There is the substantial migration task when porting Jena1 code to Jena2 code of reviewing all the I/O calls and changing them to use InputStream’s and OutputStream’s.

Now, this is my kind of technical description, …which is why it did not bite in a typical development environment…. According to the guide, the old methods are still supported, and can still be useful and I found this so when I compiled the application without making the I/O change. However, Jena now traps for the bugs mentioned in the description and issues errors – errors that are almost guaranteed to occur.

You can still use Reader and Writer, but do so when you’re working with StringBuffer in memory, or when you specifically control the string encoding. Otherwise – go with the new OutputStream/InputStream objects. Only problem is, according to the Rush I/O guide example, to access the new OutputStream class, RDFWriter, use getRDFWriter. This was a typographical error, and to get RDFWriter, use getWriter on the model object, passing in an optional string with the serialization language. The default serialization language, RDF/XML, works so we don’t need to pass in the string.

The change to the code to use RDFWriter in the updated application is (outputting to System.out):

          // Print RDF/XML of model to system output
          RDFWriter writer = model.getWriter();
          writer.write(model, System.out, null);

 

Easy enough to change. The complete new tiny application that creates an RDF model with one resource and a repeating property, printed out to system is:

import com.hp.hpl.jena.rdf.model.*;
import java.io.FileOutputStream;
import java.io.PrintWriter;

 

public class pracRDFFirst extends Object {

public static void main (String args[]) { String sURI = “http://burningbird.net/articles/monsters1.htm”; String sPostcon = “http://burningbird.net/postcon/elements/1.0/”; String sRelated = “related”; try { // create an empty graph Model model = ModelFactory.createDefaultModel();

// create the resource Resource postcon = model.createResource(sURI);

// create the predicate (property) Property related = model.createProperty(sPostcon, sRelated);

// add the properties with associated values (objects) postcon.addProperty(related, “http://burningbird.net/articles/monster3.htm”); postcon.addProperty(related, “http://burningbird.net/articles/monster2.htm”);

// Print RDF/XML of model to system output RDFWriter writer = model.getWriter(); writer.write(model, System.out, null);

} catch (Exception e) { System.out.println(“Failed: ” + e); } } }

 

Compiling the application and running it gives us the following serialized RDF/XML:

<rdf:RDF
    xmlns:j.0="http://burningbird.net/postcon/elements/1.0/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
  <rdf:Description rdf:about="http://burningbird.net/articles/monsters1.htm">
    <j.0:related>http://burningbird.net/articles/monster3.htm</j.0:related>
    <j.0:related>http://burningbird.net/articles/monster2.htm</j.0:related>
  </rdf:Description>
</rdf:RDF>

 

That’s it, an application that compiles and runs within Jena2, and a remarkably pain free migration. Of course, this was a small application. Next essay in this series, we’ll start looking at slightly more complicated applications. I’m sure the headache factor of the migration will increase as the complications in the applications increase. Isn’t there a law saying this is so?