Awesome zooming art
How cool is this? Really, give it a try.
Nip/Tuck is getting even more great than it started. Slight reduction in humour, but
so good. Scratch Wednesday nights out of my calendar.
Now to decide whether to upgrade to
OmniWeb 5.1b1….
Oh, and to continue the schizophrenic linking:
how to enable email aliases in Mail. Very handy — now each of my University addresses all count as the same account!
Posted at 2004-10-06 16:01:30 by Richard • Link to Awesome zooming ar…
, trackbacks.
The perfect Lisp environment
- Install vimsh and VIlisp (Vim scripts) into your own Vim script location (for me, ~/.vim/plugins).
- Make sure you have a Lisp installed; I use OpenMCL.
- Write a short shell script in your $PATH, pointing towards the funnel.pl script provided by VIlisp:
#!/bin/sh
echo Starting OpenMCL listener...
export PERL_RL=Gnu
~/.vim/plugins/vilisp/funnel.pl ~/.lisp-pipe openmcl
echo Finished Lisp listener.
Set this to executable, and call it lisp. - Start the Mac-native Vim executable. Resize to your preferred dimensions, and set a nice, anti-aliased font (set gfn=Bitstream\ Vera\ Sans\ Mono:h12 works for me).
- Start vimsh by sourcing the file, as described in the README. I alias this to \sh. You now have a new shell window.
- Insert the text “lisp”, and hit enter. You now have a running Lisp inside your Vim session.
- Start writing some Lisp!
The downside? It doesn't seem to work properly. It does actually connect, but something to do with my environment is stopping
vimsh being able to pick up notifications from OpenMCL, so I don't see output until I type in the fake terminal. I have the same problem, I think, when I run it outside Vim in the Mac terminal — however, it works fine in Apple's X11.
Further investigation needed, but it's very promising! Couple this with
file-explorer (try editing a directory, then using
o to open a Lisp file), and you've got a complete Lisp IDE!
Check out a
screenshot of my setup.
Posted at 2004-10-06 10:20:58 by Richard • Link to The perfect Lisp e…
, trackbacks.
URI fragID debate
There's a good discussion going on at the moment on the RDF Interest W3C list, with Patrick Stickler advocating the avoidance of fragment IDs in URIrefs. This is an excellent point:
- convenience: dereference of the URI gets the ontology (schema) without any special server configuration
Err... yes, that's the argument, but IMO it's deceptively false because it is based on presumptions about schema management practices which are *known* to not encompass common practice.
You only get the whole ontology, and hence the whole definition of the term, IFF the entire ontology and all authoritative knowledge about all terms included therein are accessible via a single representation, which presumes a single document.
If the ontology is defined and managed in a modular fashion using a number of distinct schemas, then dereferencing the base PURI of a SURI denoting a term may only result in partial knowledge about that term, as there may be key knowledge about that term defined in other schemas/documents/etc.
While such a methodology might work for small ontologies and small applications, I think it's been sufficiently demonstrated that such an approach does not scale; and the fact that there exist deployed systems with ontologies which (a) are defined and managed in a modular fashion, and/or (b) already utilize PURIs to denote their terms, it is *very* unrealistic, not to mention unreasonable, to presume that at this late stage such a methodology could be foisted onto the web and semantic web communities as the "right" way to do things.
Also, exactly why would an agent want to always get the entire ontology (think CYC, Wordnet, etc.) just to find out what a few *specific* term mean? A parallel would be having to download an entire mirror of a website to access a single page of that website after downloading the whole shabang. Yes, for tiny websites accessible via fast network connections, that could work, but it certainly wouldn't scale.
I may have to consider my own position… I see the arguments for both sides. Certainly with URIQA Patrick's position becomes nearly best-practice. Hmmm.
Additional knowledge: A “PURI” is a Primary URI (one without a fragID); a “SURI” is a Secondary URI (one with a fragID). For comparison, the OpenCyc ontology in OWL is 24MB — an agent asked to retrieve
http://www.cyc.com/2004/06/04/cyc#N_25InchTelevisionSet has to download 24MB, rather than 8 lines, of RDF.
Posted at 2004-10-06 08:54:40 by Richard • Link to URI fragID debate
, trackbacks.
