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.
So, if it's known that :~foobar works at :~workplace it stands to reason that there's no reason to write the same thing twice. Rather, the correct approach would be to reference the latter's work phone number in the former's work phone definition.
There doesn't appear to any way to do this RDF; specifically to
reference a discreet subset of another resource's properties. I was
able to find a proposal descrbing
a fragment identifier syntax [in] RDF
but it is only a
proposal and already three years old.
More importantly, my own needs for this kind of data involve being
able to process it with XSLT. No, I haven't had a sudden change
of heart about RDF/XML, but judicious use of xsl:template match
= "..."
has made it suck just a little less.
Enter XInclude. The following is valid RDF that doesn't really help
you connect the dots in a directed graph context but since you can't
do that anyway, it doesn't cost you anything either. On the other hand
it makes managing, and rendering, disparate but related pieces of data easier
.
<rdf:li rdf:parseType = "Resource"> <xi:include xi:href = "x-urn:aaronstraupcope:knows:who:~workplace" xi:xpointer = "xmlns(r=http://www.w3.org/1999/02/22-rdf-syntax-ns#) \ xmlns(f=http://xmlns.com/foaf/0.1/)xpointer(*// \ r:Description/r:type[@r:resource= \ 'http://xmlns.com/foaf/0.1/Org']/following-sibling::* \ [name()='vcard:TEL']/r:type[@r:resource= \ 'http://www.w3.org/2001/vcard-rdf/3.0#work']/parent::*/ \ child::*)" /> <!-- I am still trying to figure out why IsaViz spazzes out when I add a xi:fallback directive --> </rdf:li>
You may want to poke your eyes out after looking at that for too long but, then, nothing's for free and it's the kind of hairiness that could fairly easily be hidden by a GUI client. It goes without saying that the query itself could be optimized.
If, like me, you are using URNs as URIs you'll need to add corresponding
rewriteSystem
entries in your catalog.xml file so that
the XInclude processor is able to resolve the path to the resource
you're pointing to.
<rewriteSystem systemIdStartString="x-urn:aaronstraupcope:knows:who:~" rewritePrefix="file:///path/to/you/know/who/" />
Later: the following fixes the bugs described above and
doesn't care whether or not phone numbers are wrapped in a
rdf:Bag
container. It also makes sure that only telephone
numbers for a specific resource are included, in case there are
multiple resources defined in a single document:
<xi:include xi:href = "x-urn:aaronstraupcope:knows:who:~workplace" xi:xpointer = "xmlns(a=x-urn:aaronstraupcope:knows:who:~') \ xmlns(r=http://www.w3.org/1999/02/22-rdf-syntax-ns#) \ xmlns(f=http://xmlns.com/foaf/0.1/) \ xpointer(*//r:Description[@r:about= \ 'x-urn:aaronstraupcope:knows:who:~workplace' \ ]/child::*[namespace-uri()= \ 'http://www.w3.org/2001/vcard-rdf/3.0#' \ and local-name()='TEL']/descendant-or-self::*/ \ r:type[@r:resource='http://www.w3.org/2001/vcard-rdf/ \ 3.0#work']/parent::*/child::*)" />
Command-line tool for updating multiple images from a single jpegrdf dump.
As it is currently written the -rdf option for jpegrdf expects a single description for a single image. This is fine if you only need to update a single image but a pain if you are trying to update many images in one swell foop.
I had to write it when I changed where#qc-montreal
to
where#montreal
and needed to update ~ 1000 images.
I will post these stylesheets in the next day or so...
#!/bin/sh # currently requires the saxon:distinct() # function- I gather the xsltsl libraries # define similar hooks but I haven't tested # them yet # I know this isn't how you're supposed to # load java thingies : me.the.java.way.can.Bite() EXEC_SAXON='javavm -jar /usr/local/share/java/classes/saxon.jar' # XSL_EXPAND inherits : # /home/asc/lib/xsl/rdf/expand-resources.xsl # base class/framework for expanding resources # /home/asc/lib/xsl/rdf/expand-wordnet.xsl # the rdf wordnet output is especially verbose # so we perform some additional hoop-jumping # /home/asc/lib/xsl/rdf/expand-asc-knows.xsl # glue to expand x-urn:aaronstraupcope:* resources XSL_PRUNE='/home/asc/lib/xsl/jpegrdf/prune-exif.xsl' XSL_EXPAND='/home/asc/lib/xsl/jpegrdf/expand-resources.xsl' # dump.rdf is the output created by # jpegrdf -s ~/photos/*/*/*/*.jpg PHOTOS='/home/asc/photos' DUMP=${PHOTOS}/dump.rdf FINAL=${PHOTOS}/final.rdf # see below TMP1=${PHOTOS}/tmp1.rdf TMP2=${PHOTOS}/tmp2.rdf TMP3=${PHOTOS}/tmp3.rdf # first remove all the exif properties # except dateTime; further munge dateTime # into a resource ${EXEC_SAXON} ${DUMP} ${XSL_PRUNE} > ${TMP1} # do a first pass and try to expand # all the foreign resources in the # document - at a minimum this will # expand x-urn:asc:knows:where# / vcard # locality resources. think : # <rdf:Description rdf:about = "some-picture.jpg"> # <dc:coverage rdf:resource = "x-urn:asc:knows:where#montreal" /> # </rdf:Description> # <rdf:Description rdf:about = "x-urn:asc:knows:where#montreal"> # <rdf:type rdf:resource = "http://www.w3.org/2001/vcard-rdf/3.0#Locality" /> # <dc:title>Montréal</dc:title> # <vcard:Region rdf:resource = "x-urn:asc:knows:where#qc" /> # </rdf:Description> # <!-- and so on --> ${EXEC_SAXON} ${TMP1} ${XSL_EXPAND} > ${TMP2} # this is a pretty clunky approach but # it works as a proof of concept: do another # two passes over the output in order to # expand vcard locality/region and then # region/country resources. # a better way to do this would be to create # separate stylesheets to expand only regions # or countries since there may be other second # or third level resources that you don't care # about expanding. # at a minimum there are hooks to prevent the # same resource from being expanded twice in # the output document ${EXEC_SAXON} ${TMP2} ${XSL_EXPAND} > ${TMP3} ${EXEC_SAXON} ${TMP3} ${XSL_EXPAND} > ${FINAL} # clean up rm ${TMP1} rm ${TMP2} rm ${TMP3}
Since I've finally managed to get
jpegrdf
working I've been farting around adding different kinds of
locative
data in the absence of, and notwithstanding, automagic GPS goodness.
The following examples are the results of some experiments that may change but seem to hit pretty close to my personal 80/20 mark (where being able to read and write, not to mention query, this stuff quickly is of premium importance.)
Given the following namespaces :
@prefix : <#> . @prefix dc: <http://purl.org/dc/elements/1.1/title> . @prefix where: <x-urn:aaronstraupcope:knows:where#> . @prefix rue: <x-urn:aaronstraupcope:knows:where:qc-montreal:rue#> . @prefix blvd: <x-urn:aaronstraupcope:knows:where:qc-montreal:boulevard#> . @prefix ruelle: <x-urn:aaronstraupcope:knows:where:qc-montreal:ruelle#> .
This picture gets assigned the following data, which is pretty straghtforward :
<20040424-qc-montreal-terres_urbaines.jpg> dc:title "Terres Urbaines" ; dc:coverage where:qc-montreal ; where:site rue:marquette ; where:near blvd:du-mont-royal .
This one
is pretty much the same as the last one but the
near
property is replaced by
corner
. Is this sign
really
on the corner? No — not enough to satisfy
our new robot overlords
, anyway. But seriously it's not like
this data is for dropping bombs on people
. If either one of us was trying to give the other directions — stop, stop now, and don't tell me you're going to beam me GPS coordinates unless you want to get slapped; you know who you are — we would fudge them the same way and be no worse for it.
<20040424-qc-montreal-runs_buses.jpg> dc:title "Runs with Buses" ; dc:coverage where:qc-montreal ; where:site blvd:du-mont-royal ; where:corner rue:berri .
On the other hand, the picture associated with this post depicts something that really is on a corner :
<20040424-qc-montreal-god_juggling_donuts.jpg> dc:title "The God of Juggling Donuts" ; dc:coverage where:qc-montreal ; where:site ruelle:unknown ; where:corner ruelle:unknown ; where:near blvd:du-mont-royal , rue:drolet .
Now that we've given the pot smokers in the audience a few moments to giggle and nod knowingly to each other I will note that without creating a magic RDF Bag of Holding it's not possible to indicate that the two corners are the same : unknown, except relative to some other street. So, you fudge it again and assign an unknown
site
and an unknown
corner
on the grounds that, given the way the graph gets built, you can still find what you're looking for.
There are
site
s which are nice and vague and have a higher precedence than a
corner
which has hight precedence than something that is
near
. Streets, avenues, and such are all assumed to live in a namespace specific to their locality because anything else starts to smack of a grand unifying theory and who really has the time?
I suppose it would be useful to extend properties like
near
to add some sort of spacial element like, say,
-e
for East. But let me just point out that in Montréal
East
means anything on one side of the Main and
South
means anything towards, and beyond, the old city. Neither of which are
true
statements since both are off by about forty-five degrees. No one in Montréal cares.
$> jpegrdf -al dc:title 'hello world' ~/photos-tmp/img_1339.jpg $> jpegrdf -ar dc:coverage x-urn:aaronstraupcope:knows:where#qc-montreal \ ~/photos-tmp/img_1339.jpg $> jpegrdfify ~/photos-tmp/*.jpg [img_1331.jpg] move to /home/asc/photos/2004/03/30/20040330-img_1331.jpg [img_1332.jpg] move to /home/asc/photos/2004/03/30/20040330-img_1332.jpg [img_1333.jpg] move to /home/asc/photos/2004/04/04/20040404-img_1333.jpg [img_1334.jpg] move to /home/asc/photos/2004/04/04/20040404-img_1334.jpg [img_1335.jpg] move to /home/asc/photos/2004/04/11/20040411-img_1335.jpg [img_1336.jpg] move to /home/asc/photos/2004/04/16/20040416-img_1336.jpg [img_1337.jpg] move to /home/asc/photos/2004/04/16/20040416-img_1337.jpg [img_1338.jpg] move to /home/asc/photos/2004/04/18/20040418-img_1338.jpg [img_1339.jpg] move to \ /home/asc/photos/2004/04/18/20040418-qc-montreal-hello_world.jpg
Note that the program is not at all graceful about dealing with non-ASCII characters — it doesn't. I am aware of this and it is considered a bug. However, it's not actually a problem for me so I'm not sure how soon I'll get to it. Patches are welcome.
Trying to decide if, and how, to make this play with the so-called “w5” application” — not entirely sure what the benefit would be. Maybe as a guide and a grammer for extending the API to limit queries based location or keywords. I think this would place too high a burden on people running servers so I doubt it will happen.
Trying to decide if, and how, to make this play with the images that show up here every once in a while . At least passing date information and maybe a couple keywords.
Trying to decide how to automate that process and how Norman Walsh's jpegrdf tool plays with the RDF tools for managing photographs that I started writing — update : I solved this one enough for my liking by writing jpegrdfify
(Trying to decide how Java programmers would survive without shell scripts for generating those goofy CLASSPATH statements.)
Trying to decide who the first person to connect their photo management software to their address book will be and how they will account for the fact that out of roughly 38, 000 individual email messages I have collected just over 5, 000 unique email addresses. Actually, I sort of enjoy this one because it's
the kind of statistic
that makes
usability experts
get all weak in the knees.
Trying to decide if, and how, to deal with the fact that there doesn't seem to be
any generic way
to tell an RDF parser that
x-urn:foo:bar:(.*)
really means
/home/asc/foo/bar/$1
.
Trying to decide what kind of punishment to metre out to the next person who tells me the solution to the problem is to
add an entry in your DNS table
.
Trying to imagine writing regular expressions as RDF statements which is a good as a time as any to stop.
Or: RDF/XML must die.
So, after a little bit of thought I decided to use RDF for the so-called “w5” application 's config file. I did this because there may eventually be support for multiple protocols. I like having a single description for each protocol and referencing it from within each service description. Then I can simply poll an rdflib instance for service subjects whose protocol predicate matches [insert protocol URI here]. And, you know, if there was only ever a single suitable application for XML it would be config files .
There's the rub; here's the salt.
After deciding to use RDF I spent a little more time and tried to develop a representation for the config file that would be terse and easy enough that a lowly human could read it. More importantly they could massage it by hand or a separate program. Every day I am annoyed that there doesn't seem to be any way to massage my web browser's bookmark file and then kick the program so that it will load the new data in to memory rather than overwriting my changes when it quits.
Maybe you want to pull down your best friend's list of random image servers and add them to your own. Via a cron job. Transparently, while the so-called “w5” application is running. Whatever, that's your business. It's not a hard problem and you should be able to do it.
So, that decided, I plodded away on other things and tried to ignore that which I knew was coming. This isn't the first time I've tried to create an RDF friendly XML application and I know that if the two play at all, they don't play fairly . But sweet Jesus I was not prepared for rdflib to read this and then serialize it as this .
What collective brain-freeze gripped the RDF weenies that they so blithely assumed generating multiple representations of the same data as disconnected as these was a good thing? Or that it should be allowed to happen at all? Please, don't say it. I know that an RDF thingy is a directed graph and that there are different ways of showing the data and that this is a Feature. And I know that it's only supposed to be handled by machines and persons of a Higher Order, which is bit like saying, circa 1992, that web pages will only be edited in WYSIWYG applications.
But to my naïve eyes the only
design goal for XML
that the RDF weenies paid any attention when they wrote the spec for RDF/XML was #10 :
Terseness in XML markup is of minimal importance.
All the other points on that list were seemingly overlooked by the desire to feed our new Robot Overlords.
The point is that RDF/XML essentially mandates that you have an RDF parser in order to manipulate any of that fancy meta-data you've collected. Anything else and there's just too much room for error in interpretation, whether it's done by an XML parser or a human being. I have nothing against machine processing, per se, but when it prevents actual people from doing the same by hand that's just a Bug.
Damn it Jim, I'm your friend — not a node!
Or a lump of coal.
The plan is to make pretty pictures out of this mess and finally learn GSS at the same time.
update — Well, this is not really what I was after : The yellow circles are ideas or keywords, pink are place, red organizations and green people. The orange boxes are Dublin Core title elements. And all those little black dots hovering over the blue lines are strings identifying a predicate.
This is way more than I want, or need, to see. I want to make the predicate strings go away entirely. I want to replace the strings in each subject (the circles), which you don't see because I
cleverly
assigned them a 1pt font size, with the value of their
dc:title
and hide the child element altogether.
And maybe do something — fuck, anything — to tidy up these layouts that span entire football fields.
I will continue to poke at it, but this sort of stuff appears to be outside the scope of the GSS spec .
Meanwhile, IsaViz is pretty cool though I can't see how anyone manages to use it to good effect without a four by six foot monitor...
This is an RDF representation of * (ed.) the New York Times references in its articles. The format for this document is still a (slow) moving target and may change.
Go now, and build something interesting . I haven't decided how often I will update these files but I am thinking something like once a week.
The
RDF
-ness was only because it makes life that much easier for the monster wonks out there. Rest easy, these are not the
rdf:Bags
you are looking for. I don't share
Bill's sentiment
— in that every list of
RDF
thingies I've seen has ended up a horrible mess of incomprehensible jibberish — but he does have a point. And it makes for more people at the party.
The rest of you, if you find yourself caring about this sort of thing, can just hold your nose and
s/rdf/my little pony/gm
.
So I'm announcing PyPNG! A very small and rather poor Python (plus a smidge of C to do CRCs) library with grand ambitions. At the moment I can copy a PNG file (by reading the chunks, and then writing them again), display the text chunks, et la piece de resistance: a tool to set the content of an arbitary text chunk! PNGs with embedded RDF, here I come.
Once I've fiddled with the library design a little I'll write a PNG Explorer (hmm, png:/// in Nautilus is tempting) and a Metadata Editor for PNG files. Then I'll try and do exactly the same for JPEG files.
I hate duplication of information. For example, the fact that Dan was born and has not yet died, implies that he has a birthday. Last tuesday, most recently, in fact. Recording Dan's birthday in one place and the repeating appointment to remind me of his birthday in another place is wrong. Instead, I use rules.
The best way to think about this is as a remix: the taxonomy is an automated remix of the narrative content on the site, except instead of chopping up a ballad to turn it into house music, we're turning narrative content into an annotated timeline. The content doesn't change, just the way it's presented.
mozCC is an extension for Mozilla Firebird which scans pages for RDF, specifically embedded Creative Commons licenses. When a license is detected, mozCC does two things. First, it scans for license information pertaining to the current web page and places relevant icons on the status bar. Second, it enables a button on the toolbar which allows you to explore the parsed licensing metadata.
<r:ingredient>
<r:Ingredient>
<!--...-->
</r:Ingredient>
</r:ingredient>
...blocks. I note with a dull smile that I don't understand why the collection of ingredients is considered a Resource
but the set of directions are a Collection
and individual ingredients don't appear to be anything at all.Everywhere there are little girls in suits Running around with black balloons Munching on donuts made of edible oil
You don't need to tell me who "to raise a glass to", you fucking idiot -- I raise six glasses every night, just to get drunk enough to love this country like I did as a kid: without feeling like it's using me.
Categories
and Zeldman
functions are gone, added
support for REST interface (including 2-url form) and support for RPC categories. Still considering
whether or not to submit this to the CPAN. see also : docs
Cynosure \Cy"no*sure\ (s?"n?-sh?r or s?n"?-sh?r; 277), n. [L. Cynosura theconstellation Cynosure, Gr. ????? dog's tail, the constellation Cynosure; ????, ????, dog + ???? tail. See{Cynic}.] 1. The constellation of the Lesser Bear, to which, as containing the polar star, the eyes of mariners and travelers were often directed. 2. That which serves to direct. --Southey. 3. Anything to which attention is strongly turned; a center of attraction. Where perhaps some beauty lies, The cynosure of neighboring eyes. --Milton. web1913
cynosure n : something that strongly attracts attention (as the north star attracts mariners); "let faith be your cynosure to walk by" wn
Wastrel \Wast"rel\, n. 1. Any waste thing or substance; as: (a) Waste land or common land. [Obs.] --Carew. (b) A profligate. [Prov. Eng.] (c) A neglected child; a street Arab. [Eng.] 2. Anything cast away as bad or useless, as imperfect bricks, china, etc. [Obs. or Prov. Eng.] web1913
wastrel n : someone who dissipates resources self-indulgently [syn: {waster}] wn
Zeitgeist \Zeit"geist`\, n. [G.; zeit time + geist spirit. See {Tide}, n.; {Ghost}, n.] The spirit of the time; the general intellectual and moral state or temper characteristic of any period of time. web1913
Zeitgeist n : the spirit of the time; the spirit characteristic of an age or generation [syn: {Zeitgeist}] wn
Evanescent \Ev`a*nes"cent\, a. [L. evanescens, -entis, p. pr. of evanescere.] 1. Liable to vanish or pass away like vapor; vanishing; fleeting; as, evanescent joys. So evanescent are the fashions of the world in these particulars. --Hawthorne. 2. Vanishing from notice; imperceptible. The difference between right and wrong, is some petty cases, is almost evanescent. --Wollaston. web1913
evanescent adj : tending to vanish like vapor; "evanescent beauty" wn
Abominate \A*bom"i*nate\, v. t. [imp. & p. p. {Abominated}; p. pr. & vb. n. {Abominating}.] [L. abominatus, p. p. or abominari to deprecate as ominous, to abhor, to curse; ab + omen a foreboding. See {Omen}.] To turn from as ill-omened; to hate in the highest degree, as if with religious dread; loathe; as, to abominate all impiety. Syn: To hate; abhor; loathe; detest. See {Hate}. web1913
abominate v : find repugnant [syn: {abhor}, {loathe}, {execrate}] wn
http://aaronland.info/weblog/category/(NAME|ID)/rss
. You can see an example of where all this nonsense might get interesting at the perlblog. You is all still in the proof of concept stage, so you should expect breakage and random weirdness for a while yet.
Assuming all the boring namespace setup, consider the following chunk of RDF to describe a person and their phone numbers:
Similarly, consider a second chunk of RDF to describe an organization and it's phone numbers: