7D twisting and tagging
I've been thinking about the terms we should use to machine tag our 7d tiltometer metadata.
The terms:
1. Altitude
2. Latitude
3. Longitude
4. Compass bearing
5. Tilt
6. Orientation
7. Timestamp
Some semantics:
By tilt, we mean rotation around X axis - or, are we pointing the camera at our feet?
By orientation, we mean rotation around Z axis - or, are we doing a wacky half-portrait half-landscape shot?
By compass bearing, we mean rotation around Y axis. North, East, North-North-East. Oh, you know what a compass looks like..
OK, I've got two aims:
A. Use the semantically correct term.
B. Use whatever everyone else is using - accept existing data.
Since we're hoping to make use of user-contributed photo metadata other than that we've cooked up ourselves, B. is really important to us.
altitude, latitude, longitude -> geo:
Ok, these first 3 are a no-brainer on both criteria: geo: is the preferred ns prefix for the swig Basic Geo (WGS84 lat/long) Vocabulary. And, thousands of taggers already voted with their fingers: 
compass bearing, tilt -> ge:
Google Earth / KML / FlickrFly offer ge:tilt (meaning the same as we do), and ge:heading (meaning compass bearing).
The use of 'ge' seems a bit unsatisfactory to me. 'G'oogle 'E'arth describes the application, not the data. But ho hum, 9268 people don't agree:
, so that's a decider for me.
We are also stuck with the problem that FlickrFly have been recommending 'head', while the kml vocab defines 'heading'. 'Head' is the statistical winner. But perhaps we should double-tag and use both?
Orientation -> exif ?
ge:rotation doesn't quite capture our meaning. Strictly, exif:orientation's value should be restricted to 4 possible positions. But, it does have that usability factor - it's meaning is understandable.. so I think we'll cheat and use it anyway for now.
timestamp -> dc: / exif: ?
This is a tricky one. What do people actually do? Well.. mainly nobody tags this at all - this data belongs in the EXIF pile that your camera puts there for free. 
Given that.. I'm tempted to go with exif on the basis that it's more familiar to amateur photographers, and thus easier to type in the box. (and persuade others to type in the box..?)
Really, we're trying to squeeze an exif-shaped datum into a tag-shaped hole on this one. Perhaps we should be querying the exif data instead?..
Provisional quakr set:
1.geo:alt
2.geo:lat
3.geo:long
4.ge:heading
5.ge:tilt
6.exif:orientation
7.exif:dateTime
5 comments:
Hey.
I like most of it but I got two big problems and the beginnings of a discussion about numbers...
1) Exif:Orientation
All the photos I take using my camera phone are automatically Exif'd with a rubbish value for this. If we choose to believe that the original picture was taken in this orientation, then we'll simply get rubbish information. I think we should either look for something that is NOT already used, or allow a tag that can overwrite the Exif info. I'm thinking of something new here possibly; Cam:Orientation? Quakr:Orientation?
2) The ZOOM problem...
I think / am sure that we need another item of data before we can render all the pictures correctly into the Quakr Viewr, Consider the following pictures...
car park, zoomed out
and
car park, zoomed in
In these two photos, all the above tags/data would match, but we can't say that the two photos should be placed in exactly the same space in the Quakr Viewr. We need to somehow note the "amount of zooming in" that any photo was taken as in order that we can re-size the image before placing it into space. The second photo should be *shrunk* in order to fit into the middle of the first photo. Thoughts and ideas as to what information is available in order for us to do this would be good I think...
3) A starter for ten about default values for the above data and what those default values might mean; perhaps this is worthy of a second post but for now...
geo:alt = 0 if unknown (and is measured in metres?)
geo:lat & geo:long = not assumed, we choose to ignore all non lat/long'd images.
ge:heading = 0 = Taken facing North.
ge:tilt = 0 = Taken facing the ground.
exif:orientation = 0 = Taken portrait.
exif:dateTime, Should always be available.
cam:zoomedin = 0 = Taken with no zoom.
On the original recommendations, it seems like a real pain to have to mark up the photos with different namespaces. If we want to attempt to render photos that already have this data, fine... but for new photos, why not just use a quakr: namespace. Obviously, this form of laziness is not cool in semantic web terms, BUT if we want some uptake on this it might be necessary.
How about this:
1. To render existing photos with existing tags, use whatever is there (as best we can)
2. If people want to tag in the recognised semantic web way (as per Katie's and Peter's suggestions), then fine - we will be able to use those under (1) above
3. If people are too lazy for all that, accept quakr:tilt etc.
4. If people are only slightly lazy, provide them with a greasemonkey script so that they can enter everything as quakr:tilt etc. but then use the script to automate the addition of extra tags in the recommended semantic web style?
Dave,
I agree that a single consistent namespace:
quakr:x, quakr:y, quakr:z
would be easier to input.
But..
Problem 1:
We want to make use of existing data that is out there. We need to support ge:tilt etc in our app if we're going to do that. Trying to control all the data and tightly couple it with our app puts us in msoft virtual earth / google earth territory. ;)
You're right that double-tagging is an option to achieve both convenience and semantic interop:
-> We quakrers tag with both quakr:tilt and ge:tilt. We use greasemonkey script to help us.
-> We accept either as feeds to the app.
Problem 2:
What about geo: ?
Are you suggesting quakr:lat ? Isn't that just a bit weird?
hard but not,
1) You're probably right about exif:orientation, it's confusing, and could result in false data. Hmmm... let's think about it.
2) Zoom. Perhaps we need: exif:subjectDistance ?
Hey.
Hmmm... I like what you're saying about Exif:subjectDistance, but... check the actual Exif data attached by my phone-cam onto the Flickr images...
this one
and
this other one
Subject Distance Range : Distant
in BOTH cases...
Digital Zoom Ratio : 400/100
vs
Digital Zoom Ratio : 100/100
seems to be the difference in *my* case...
then I go look at a couple of photos taken by my good lady on our recent holiday with a camera that we'd switched off the digital zoom on ...
this one
and
this other one
and I see that the different *zoom levels* are noted in the ...
Scaled Focal Length : 2070
vs
Scaled Focal Length : 1060
??
hmmm. Seems this may be that little bit more complicated than at first assumed. Perhaps we should, like Dave suggests instigate a quakr:zoom tag to overwrite any confusing Exif info?
Post a Comment