drewp for 2008 October
<M <Y
M>

2008-10-05T00:38:50 SHDH 27:

I went to SHDH 27 and met with Drew Hess, David Reid, Joel Frasunic, and others.

At first I did some sysadmin maintenance of my personal photo archive and tagging system, which uses python+rdf to make pages like this.

Then I remembered there are only 25 days left on the Boards.ie competition, so I picked that up again. I asked the people around me for more ideas and got several good ones, including:

BTW, everyone who saw me demo ubigraph was impressed, so you might like it too.

 

2008-10-13T21:11:59 jott.com UX is not great:

jott.com, what's going on?

I called to record an idea I had on the drive home. This was not an expected use case for jott.com, so I'll explain it in more detail: I had an idea; I was concerned I would forget it; so I speed-dialed jott.com to speak my idea and get a transcription in my email inbox. The jott.com prompt said something like "Before you record, please listen to this special announcement. There's something new on your account at jott.com. Please remember to check your account later. Record your note now."

I forgot my note, of course. Not having to hold little todo items in my head is why I use jott.com. Apparently jott transcribes slow, confused words pretty well, although they omit muttered swearing.

When I got home, I followed the new email link to read my note, and I didn't get any important account messages. Jott does not log you in even when you click the link in the email they sent to you. That's lousy, and it's not a security issue since they know when they're sending to the same address they use for password resets.

When I did log in, all I got was "Upgrade your plan to connect to Remember the Milk by phone." I think the big news might have been this, which is a link I found on their blog.

Moral: if your product is made to gather some information quickly, gather the information before making silly announcements.

Otherwise, I highly recommend jott.com for its free transcribing of voice messages!

2008-10-13T22:38:18 rdflib vs jena graph creation APIs:

I actually looked at the jena RDF API today, and I was interested to see how graph creation compares to rdflib's style, which is the one I normally use.

From the Jena introduction (minus the model setup and some comments):

String personURI    = "http://somewhere/JohnSmith";
String givenName    = "John";
String familyName   = "Smith";
String fullName     = givenName + " " + familyName;

Resource johnSmith
  = model.createResource(personURI)
         .addProperty(VCARD.FN, fullName)
         .addProperty(VCARD.N,
                      model.createResource()
                           .addProperty(VCARD.Given, givenName)
                           .addProperty(VCARD.Family, familyName));

An rdflib python port of that:

johnSmith    = URIRef("http://somewhere/JohnSmith")
givenName    = "John"
familyName   = "Smith"
fullName     = givenName + " " + familyName

graph.add((johnSmith, VCARD['FN'], Literal(fullName)))
name = BNode()
graph.add((johnSmith, VCARD['N'], name))
graph.add((name, VCARD['Given'], Literal(givenName)))
graph.add((name, VCARD['Family'], Literal(familyName)))

If I were making a new version of the rdflib API, here's what I'd consider:

  1. Don't expose the strings of URIRefs very easily. It should be somewhat hard to examine or operate on a URIRef's string value. This is first to encourage good practices (no more "print u.split('/')[-1]" or "if 'foo' in u:") but more importantly to allow for optimizations in query engines. A backend should be able to return URIRefs containing its internal ids while a query is running, and then any URIs that make it to the result set can be looked up (if needed). Actually getting the string form of a URIRef would still be possible of course, but it might require an explicit method call. Most people's URIRef serializations are in __repr__ calls and output formats, so this change shouldn't be that noticable.
  2. Literal can still be a string subclass; BNode should not be.
  3. Like jena, don't require Literal() on strings unless they need a lang or datatype. People forget Literal() sometimes anyway, which rdflib sometimes handles. The rest of the time it corrupts your database. "hello" is pretty clearly the same as Literal("hello"), so I think it's fine to support "hello" the same way that rdflib now supports 5 to be a xsd:int literal. Another choice would be to error quickly on strings, which would be a good move if people were providing URIRefs as strings accidentally.
  4. Support graph construction APIs with named methods, like graph.node(uri1).addProperty(pred1, "value1"). These are nice for new users since they bring terminology in quickly, and some of the condensed forms seem cool.  I don't like jena's 'createNode' method name, though, since as far as your graph is concerned, nothing got created. The fact that a java Node object was created is not important. Other possibilities:
    I also obviously prefer 'edge' to 'property', since edges sound more like the free-form graph that we're making. What system would have a property whose value is another property? That's a perfectly natural RDF construct, but pred1.addProperty(pred2, pred3) doesn't look so natural. It's also less surprising that edges can be traversed both ways. Other systems with "properties" don't always support that, causing users to make redundant inverse properties where they think they might need to traverse backwards.

2008-10-13T23:37:57 Image normalization idea for light9 previews:

Original problem: I want to combine images of individual theater lights to simulate what it would look like if they were turned on in some combination of brightnesses. That's fine, but when my input image has a washed out area at the hotspot of the light, 50% of that image will not be correct. There will be a gray splotch in the shape of the hotspot. Here's a demo using a desklamp in my room:

Solution: Use High Dynamic Range images that contain relative brightnesses even inside a washed-out area. With a low-end camera like mine, I can take multiple exposures of the scene and then reassemble them automatically into an HDR image. Tools that might be able to do this include cinepaint, HDR Shop, and qtpfsgui. Then when I want to see a particular mix of lights, I add my per-light HDR images with the appropriate scale factors and clip the result to white. The result should be like I took a real photo of that light combination.

New problem: Unless my input images (HDR or not) are all calibrated to the same brightness scale, my resulting image will be incorrect. E.g. if light1 is dim and light2 is bright, my simple camera will probably auto-expose light1 to be brighter than it really is and vice versa on light2. My resulting images will be incorrectly low-contrast-- each light will have been adjusted towards the middle. If I use my digital camera to take the photos, I might be able to get some EXIF correction data. But if I use my laptop webcam, I don't think I can ever learn the auto-adjustment level. It would be nice to know the scale factor of each of the input images so we can normalize them before adding them.

New solution: After taking the per-light images, take another picture that has all the lights on (or a few pics of various known combos). Then solve for the scale factors on each light's image that would lead to the measured combo image. Each pixel in the allLights image is a combination like this:

scale1*light1(x,y) + scale2*light2(x,y) + ... = scaleAll*allLights(x,y)

There are a lot more pixels in each image than there are unknown scale factors, so this should be solvable. Once we figure out the scale factors, we can start making accurate sums of the input images.

 

2008-10-19T01:53:10 Running firefox 3.1 under 64-bit ubuntu:

If you get firefox 3.1 and try to run it on a 64-bit ubuntu hardy install, you'll probably get this failure:

./firefox-bin: error while loading shared libraries: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory

  1. Go get the i386 version of libdbus-glib and save the .deb file somewhere.
  2. Run "file-roller /tmp/libdbus-glib-1-2_0.74-2_i386.deb".
  3. Go into data.tar.gz -> . -> usr -> lib, and copy libdbus-glib-1.so.2.1.0 to your firefox 3.1 directory.
  4. Rename it to lose the ".1.0" at the end.

Now you should be able to test firefox 3.1 and play some of the videos from here. The one called 'video embedded in svg' is impressive, although on my system I only got one video at a time and the audio sync drifted. See this screencast (or youtube) for what it should look like.

2008-10-26T17:58:40 Positioning via wifi strength:

Because I just re-fixed the wifi on one of my laptops and because I just read this idea for estimating position by wifi signal strength, I started measuring the strength of my two APs and some neighbor ones as I walked around my house. The result looks like this:

I'm getting close to having my hardware arranged well enough that 4 rooms will each have their own music servers. Everything I read recommends putting all your servers together in one closet, for wiring reasons. But if I'm going to have audio, light control, and other sensors everywhere, it seems like a win to spread the computers out around the house.

There will also be a few bluetooth sensors on those machines which could let me find the position of items like guests' cell phones. I hear the signal-strength resolution on those is much worse, but just knowing who is anywhere near the house is pretty good.

[Main]

Unless otherwise noted, all content licensed by Drew Perttula
under a Creative Commons License.