RDF Mapping, Part Two
I talked with some of the folks on #rdfig today about my RDF mapping, and got some good suggestions and pointers.
Christopher Schmidt suggested using xearth, pointing me to some work already using FOAF and xearth.
I’ve added the following triple pattern on the suggestion of Morten Frederiksen to support yet another form of geo-annotation on images:
(?person foaf:name "{name}")
(?img foaf:depicts ?person)
(?img dcterms:spatial ?p1)
(?p1 cyc:near ?p2)
(?p2 geo:lat ?lat)
(?p2 geo:long ?lon)
(?img dcterms:created ?date)
So now I know that the code will work with at least one other person’s RDF photo annotations.
Even acknowledging that my use of foaf:based_near
on an image is a hack (waiting on formalization on foaf:creationEvent work), there are a lot of ways to do these annotations. So here’s what I want. I want a way to associate an property or a resource and a list of triple patterns to access the property. I could, for example, give a bunch of triple patterns (as I have for this mapping project) to associate a resource (person) with a latitude/longitude/date pair. Ideally, this would be at the RDF library level (or some intermediate level) since doing this all at the application level is what’s causing this to be so painful and inefficient.
I’d also like to be able to specify a pluggable sort function for RDQL queries. If I try to sort by ?date
, and ?date
is in W3CDate format, it should be sorted as a date. This would ideally be based on the rdf:type
of the resource, but since dates are literals, that won’t work. But I imagine that there would be all sorts of interesting ways to utilize domain-specific sort functions for things like names (by surname), dates, places (sort by distance from a base point?), and groupings: families (depth- or breadth-first traversal of family trees), coworkers (group by foaf:workplaceHomepage
), classmates (group by foaf:schoolHomepage
).
On a related topic, an SVG outline map of the world was posted to the #rdfig scratchpad. This would be ideal for my mapping work if it weren’t 421k compressed. Maybe it would be worthwhile to generate SVG maps for smaller scales based on this, though (a map only of the US, for example).