Das eez kaput! Sometime around 2002 I spaced the entire database table that mapped individual entries to categories. Such is life. What follows is a random sampling of entries that were associated with the category. Over time, the entries will be updated and then it will be even more confusing. Wander around, though, it's still a fun way to find stuff.
identifier
element to note the URI of your image. It is reserved for some random,
and possibly repeating, internal marker that your camera uses to flag
individual images. The logic here escapes me but, whatever. I want an
identifier that points to the actual image, I think, so I'll just use
the handy
dc:identifier
instead. I wrote the RDF to a separate file and then I imported it in
to an image I was munging with RDFpic. So far, so good. Next, I
immediately exported the data to another file to see what it looked
like :
<s0:http://purl.org/dc/elements/1.1/identifier>
/home/asc/tmp/photo/2003/07/19/20030719-img_0013.jpg
</s0:http://purl.org/dc/elements/1.1/identifier>
# Which in case you're not sure
# yields the following error:
107 ->xmllint ./2003/07/19/20030719-img_0013.rdf2
./2003/07/19/20030719-img_0013.rdf2:9: \
error: error parsing attribute name
<s0:http://purl.org/dc/elements/1.1/identifier>
^
Beauty, eh?browser.block.target_new_window
Mozilla pref to suppress new windows also disables the "Please wait..."
server push hack in buglist.cgi.
distributed metadata for information geeksis not really a by-line that will win you friends and influence outside a very small circle of dorks but it's cool to see this finally blossoming. I wonder if the database schema will play nicely with Class::DBI...
I found this linked from the OpenMap project (that rumbling sound you're hearing is the FOAF weenies getting excited) which is also pretty cool.Local Harvest maintains a definitive and reliable "living" public nationwide directory of small farms, farmers markets, and other local food sources. Our search engine ... helps people find local sources of sustainably grown food, and encourages them to establish direct contact with family farms in their local area.
Date: Tue, 10 Sep 2002 11:06:31 -0400 (EDT) From: Aaron Straup Cope To: Ben Hammersley Subject: the unbearable twingularity of it all >From the thinking out loud department : You might be able to rig something using Mail::Audit and the BBDB (written by Mr. Intertwingle himself.) All of which will inevitably necessitate some sort of intersecting of the BBDB and FOAF... http://bbdb.sourceforge.net/ http://search.cpan.org/author/LAXEN/BBDB-1.34/ http://search.cpan.org/author/SIMON/Mail-Audit-2.1/Audit.pm See also : http://aaronland.info/weblog/category/email/recent http://aaronland.info/weblog/archive/4058 # This part is easy and implemented in a gazillion different # ways already. I include it only for thoroughness : http://perl.aaronland.net/rss/ Cheers,
AEsthete \[AE]s"thete\, n. [Gr. ? one who perceives.] One who makes much or overmuch of [ae]sthetics. [Recent] web1913
aesthete n : one who professes great sensitivity to the beauty of art and nature [syn: {esthete}] wn
my $google = Net::Google->new(key=>LOCAL_GOOGLE_KEY);
my $search = $google->search();
# Or replace "michael boyle" with $cgi->param("query")
$search->query(qw(michael boyle));
$search->query("site:aaronland.net");
map { print $_->URL()."\n"; } @{$search->results()}
# Prints :
http://www.aaronland.net/weblog/theory/
http://www.aaronland.net/weblog/archive/936
http://www.aaronland.net/weblog/archive/1951
http://www.aaronland.net/weblog/category/40
see also : Nathan Torkington on
commercial web services
0045_
prefixes?); the meta data or commentary associated with an image; the
look and feel of the actual webpages. And while an all-in-one package
is always fun my experience has been that, in a slideshow, context,
they usually come at the price of zero-flexibility.
Apache::Album
is a pretty good example. It is a very cool and very easy widget to set
up. But, the HTML is hard-coded and meta data is stored free-form in YA
file that sits in the image directory and it only outputs HTML. So, I
spent the better part of two months, a while back, tearing the guts of
the package apart trying to make it more flexible with things like
subclasses for output formats, XPath-itis for meta data and all manner
of bells and whistles. I learned a bunch of stuff in the process but
ultimately failed to create anything more flexible or robust. One of
things I learned is that you can use ImageMagick to read and write
comments into image files which got me thinking that you could store
all of your metadata as an XML blob in the comments field. Which is
pretty interesting since when you think about it a directory listing is
basically a bare-bones slideshow. With some clever caching techniques
you could simply attach a server based handler to a directory of images
-- we'll ignore how you get the meta data in there for the moment --
and be done with it. Neat, huh? But I'm not a scholar on image formats
and I don't really know what the rules are about one application
respecting the comments that another application writes. And truth be
told, I'm not that interested in learning. So, that means we're back to
the stage where we've got a bunch of images and a bunch of XML files.
Or maybe we've got just one XML file. Either way, we've got this funny
bird that needs to be massaged before anything can be done with it. And
writing any kind of DTD is going to be a pain because everyone is going
to have some kind of random meta-ness they want added to their
slideshow. Attentive readers (or
David
who got to listen to this rant, last night) will have begun to
see
where this is going
:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" [
<!ENTITY % Slides SYSTEM
"http://www.aaronland.net/src/dtd/mod/xhtml/slide.mod">
%Slides;
]>
By redefining the XHTML
%Block;
and
%Flow;
entities, you can create a flexible slideshow format that is both
XML
fit for munging/transforming and
HTML
for easy viewing :
<!ELEMENT abstract (p*)>
<!ATTLIST abstract id ID #REQUIRED
class CDATA #IMPLIED
style CDATA #IMPLIED
title CDATA #FIXED "Abstract">
<!ELEMENT slide (meta*,a)>
<!ATTLIST slide sid ID #REQUIRED
class CDATA #IMPLIED
style CDATA #IMPLIED>
<!ENTITY % Block "(abstract,ul)">
<!ENTITY % Flow "(slide)">
The
ul
(yeah yeah, it should probably be an ordered list...) element can only
contain
li
elements.
li
elements are defined with the
%Flow;
parameter entity which means you can redefine your XHTML document to
validate as a single list, that contains one or more items. Each item
contains a "slide" which consists of zero or more meta tags (remember
them?) and a link. If all your fancy pants server tools are broken
you're still left with a list of named images that link to actual
images. Not great but better than than an XML document rendered as a
collapsible outline. So far, so good. But wait! There's more :
<Directory /path/to/image/directory>
DirectoryIndex index.html
SetHandler perl-script
PerlHandler Apache::ImageViewer
PerlSetVar ScaleSmall 25%
PerlSetVar ScaleMedium 50%
PerlSetVar ScaleLarge 75%
PerlSetVar ScaleThumb x50
<FilesMatch "index\.html$">
PerlModule AxKit
SetHandler perl-script
AxProvider Apache::AxKit::Provider::Filter
AxAddStyleMap text/xsl Apache::AxKit::Language::LibXSLT
AxAddProcessor text/xsl /site/xsl/slides/slide-tools.xsl
AxCacheDir /usr/local/www/htcache
AxDebugLevel 0
AxStackTrace Off
AxLogDeclines Off
AxNoCache Off
PerlHandler AxKit
</FilesMatch>
</Directory>
And while the example cited is mod_perl specific, there isn't much to
prevent it from being implemented in whatever environment suits your
fancy. All you need is a widget that can speak to ImageMagick and an
XSLT engine that can suck in CGI parameters :
sid
and
scale
. Those are the keys used to 1) tell the stylesheet whether or not to
render an image or an index and 2) tell the image widget which image to
display and
how big it
should be
. The next step is to write an XSLT stlyesheet to convert the XHTML
described above in to an
AxPoint
document.
download :
slide-tools 0.1
Irascible \I*ras"ci*ble\, a. [L. irascibilis, fr. irasci to be angry, ira anger: cf. F. irascible. See {Ire}.] Prone to anger; easily provoked or inflamed to anger; choleric; irritable; as, an irascible man; an irascible temper or mood. -- {I*ras"ci*ble*ness}, n. -- {I*ras"ci*bly}, adv. web1913
irascible adj 1: quickly aroused to anger; "a hotheaded commander" [syn: {choleric}, {hotheaded}, {hot-tempered}, {quick-tempered}, {short}, {short-tempered}] 2: characterized by anger; "a choleric outburst"; "an irascible response" [syn: {choleric}] wn
ls -laR
command to an FTP client and and pipe it through to a series of SAX
handlers/filters that ended with a single representation of all the
changes. I suppose you could run a daemon on the server-side, every (n)
minutes and output a dotfile for the client to read. Or maybe run a
stand-alone XML-RPC server, at the remote location, that returns a data
structure of the directory layout. If you assume that the server has
more processing power/tools than the client, there could be a second
method that accepted an XML representation of the client-side directory
structure that returns a list of changes. But the point is ...the point
is that some pointy-head somewhere is going to seize on this as an
opportuntity to write YA markup language... that this is really just a
daemon
with a dumb GUI for storing paths and an authentication. I wonder how
hard it would be to hack the
Amphetadesk
framework to do this since it's essentially the same concept : every
once in a while, do something over here with this login. see also :
XML::Directory
and
I'd love to retire XML::Handler::2Simple in favor of the forthcoming
XML::Simple
Perforce \Per*force"\, v. t. To force; to compel. [Obs.] web1913
perforce adv : by necessity; by force of circumstance wn
