Assuming all the boring namespace setup, consider the following chunk of RDF to describe a person and their phone numbers:

<rdf:Description rdf:about = "x-urn:aaronstraupcope:knows:who:~foobar">
 <rdf:type rdf:resource = "http://xmlns.com/foaf/0.1/Person" />
 <vcard:TEL>
  <rdf:Bag>
   <rdf:li rdf:parseType = "Resource">
    <rdf:type rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0#home"/>
    <dc:identifier rdf:resource = \
       "x-urn:aaronstraupcope:knows:phone-number:~123.456.7890" />
   </rdf:li>
  </rdf:Bag>
 </vcard:TEL>
</rdf:Description>

Similarly, consider a second chunk of RDF to describe an organization and it's phone numbers:

<!-- observant readers will note that this is not really
     a list of phone numbers and that if it was the
     code used to query it (below) would fail. but that's
     just syntax and doesn't change the fundamental point -->

<rdf:Description rdf:about = "x-urn:aaronstraupcope:knows:who:~workplace">
 <rdf:type rdf:resource = "http://xmlns.com/foaf/0.1/Org" />
 <vcard:TEL rdf:parseType = "Resource">
  <rdf:type rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0#work"/>
  <dc:identifier rdf:resource = \
     "x-urn:aaronstraupcope:knows:phone-number:~555.555.1212" />
 </vcard:TEL>
</rdf:Description>

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::*)" />

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...

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 .

I decided to spare a few computrons to the ongoing task of investigating whether it is realistic to at least make the next version of eatdrinkfeelgood RDF friendly. I note with interest that neither ingredients nor units of measure are defined as URIs. I note with horror the use of...

<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.