Disqus - Latest Comments for Phil Dawes

Re: One symbol, multiple meanings

Phil Dawes — Fri, 17 Jun 2005 06:49:54 -0000

Is OpenLDAP slapd? Is OpenLDAP the Foundation?

As the author of the graph you get to pick this. However, each reader will have their own interpretation and so if you want readers to understand your semantics you need to be sufficiently verbose

Re: need a name...

Phil Dawes — Mon, 27 Jun 2005 06:27:40 -0000

Omnivat … OneUniverse … FatFusion

Hmm... I like the word 'vat' - conjures up an image of fermenting gloopy stuff.
DataVat sounds a bit tripe tho. I really need a better word for 'data'. (Not sure there is one)

(Thanks for all the suggestions btw!)

Re: comments on rel-tag microformat

Phil Dawes — Fri, 29 Jul 2005 11:26:01 -0000

Prentiss Riddle writes:
Maybe a URL-free version of this idea would have been better, but it's not true that Technorati has excluded other players on this point.

Hi Prentiss,
My concern wasn't with any technorati-centricness of the scheme - it's clear technorati are being very open and keen to produce standards for the benefit of all. Just that I wasn't sure the URL portion added any value in return for its additional complexity over a simple tag, and may have implied semantics* not adequately supported by the scheme.

(i.e. 'I mean the same as all the other people using this tag in the tagspace')

Re: comments on rel-tag microformat

Phil Dawes — Fri, 29 Jul 2005 11:26:33 -0000

Ryan King writes:
I don't think it implies that others who've used the same tag mean precisely the same thing, just as is the case in folksonomies such as del.icio.us.
You don't have to link to Technorati's tag space if that doesn't suit you. You can link to any tag space you like.
Have a URL allows readers to see some explanation of the tag. For example I link my tags to wikipedia often (even though I work for Technorati :)). The wikipedia explains what I mean by the tag. Technorati tags are useful in that they say "this post is a part of that conversation" and work pretty well for that.

Hmmm.. Maybe. I guess I'm stuck on URIs=precision because I've been so involved with RDF in the past.

<span rel="tag"></span> is not valid (X)HTML, nor is the 'rel' attribute meaninful in this case. As it is defined as: "describ[ing] the relationship from the current document to the anchor specified by the href attribute." With your proposal, there's no relationship to describe.

Oops - that probably should have been <span class="tag">apple</span> or something.

Re: need a name...

Phil Dawes — Mon, 01 Aug 2005 10:49:42 -0000

I've given up trying to find a cool word for data.
Am thinking I'll go with 'jamvat' - at least until somebody comes up with something I like better.

Expect a jamvat release and demo soon!

Re: Announcing JAM*VAT - the structured data aggregator

Phil Dawes — Wed, 10 Aug 2005 19:21:58 -0000

I've just realised I haven't credited Daniel Krech for his excellent RDFLib library which is bundled and used in the RDF importer. I'll do a new release of the software tomorrow to rectify this - sorry Daniel!

Re: Announcing JAM*VAT - the structured data aggregator

Phil Dawes — Wed, 10 Aug 2005 19:25:55 -0000

Software is licensed bsd-style (in case anybody is interested).

Re: Tagtriples + identity precision

Phil Dawes — Thu, 15 Sep 2005 17:55:26 -0000

This description capability even allows JAM*VAT to import RDF with no loss of information (i.e. you could export it back into RDF if required). It does this by tagging each human-readable symbol with the URI used in the RDF.

E.g. the URI:<http://phildawes.net/phil> gets translated into the symbol 'phil', and the statement:

phil tag http://phildawes.net/phil

(This tags the symbol 'phil' with the URI). The JAM*VAT aggregator uses the 'tag' property to help manage identity between graphs. 'Tag' in JAM*VAT fulfils a similar role to a tag in del.icio.us - i.e. another symbol that can be used to categorise the target.

Re: Tagtriples + identity precision

Phil Dawes — Fri, 16 Sep 2005 05:10:09 -0000

Hi Laurent,

I've read your pages, but I'm afraid I'm not sure if I understand what you are getting at.

Am I correct in thinking that you want to replace a URI with a string of associated words. Systems then disambiguate the meaning via the connected set of words?

e.g. 5:apple,8:computer ?

Also, why bother with the netstring numbers? - for the sake of simplicity, why not (apple,computer) or something?

Re: URIs make metadata complicated

Phil Dawes — Tue, 20 Sep 2005 18:28:30 -0000

Hi Jimmy,

Jimmy Cerra writes:

Why can't you use blank nodes if you can't use URI References? Resources don't need to be named, and sometimes (like in a database-like environment) most resources will be unnammed.

If you are willing to step up to OWL, then with inverse-functional properties you can still identify things with a “public key” like structure. However, you can do that anyway with any practical RDF application too.

Actually I attempted to follow this approach at work for a while (ala foaf), and was indeed willing to step up to OWL - my veudas triplestore supported inverse-functional properties for this reason (via a forward-chaining reasoner e.g. see circa sep 2004 if you're interested!).
It did make things complicated though - IFP smushing was slow, and unless you're going to give people cookie-cutter examples then they really do need to understand IFPs.

e.g. people don't naturally write:

<pre>
<project>
<name>My Application</name>
<maintainer>
<foaf:Person>
<foaf:mbox>foo@example.com</foaf:mbox>
</foaf:Person>
</maintainer>
<project>
</pre>

Unfortunately cookie-cutter examples kind-of miss the point - you might as well be translating people's data into RDF for them. The real goal for me at work was that people could come up with their own data (from their own systems) that could be aggregated and merged usefully, otherwise it's not really worth the trouble.

...
Also, the only requirement is that URI References are semantically uniform across the graphs you use it in. Problems happen when you merge graphs that have different semantics with the same URI Reference, but sometimes the types of graphs merged are small and managable.

If you have to merge with large numbers of graphs or with the whole Semantic Web for all of eternity, then I can see where minging URI References is a problem. But that is a social problem with naming itself and not RDF.

I think it's a problem with globally scoped naming. - The RDF model doesn't allow for any skewing of meaning with context. You can't change society, and global adoption is one of the aims of the semantic web.

To be honest I think this sort-of illustrates a wider point - if you're just going to work on small manageable sets of data then why bother with complex URI and RDF machinery that inhibit adoption? - It strikes me as quite ironic that the very RDF machinery that was intended to facilitate this large-scale aggregation of data actually ends up inhibiting it.

Re: URIs make metadata complicated

Phil Dawes — Tue, 20 Sep 2005 19:01:00 -0000

Bill de hOra writes:
Strictly speaking, (4):

“URIs are globally scoped, which means they need to mean the same thing in any context.”

isn’t true, for RDF. URIs don’t have meaning they have denotations; denotations are assigned (”distributed”) and that can be done in a local scope. In theory, when you merge data, you determine that the same URI has different referents via logical inconsistencies; in practice you have domain experts and data modellers look analyse the data (just like you do with relational database integrations).

Ok - that makes sense (although I haven't read that anywhere before - but then I'm starting to fall behind with the literature ;-) ).

Which means that there's probably a lot of scope for simplifying RDF - you can't throw a baby out with the bathwater if it wasn't in the bath to begin with.

Re: URIs make metadata complicated

Phil Dawes — Thu, 22 Sep 2005 02:48:02 -0000

Joshua Tauberer writes:

> (1) URIs don’t allow you to use existing identity schemes.

Exactly because to do so would be ambiguous. How do you know what identity scheme is being used?

Context tells you this.

> (4) URIs require a level of precision in ‘meaning’ that is hard to attain. URIs are globally scoped, which means they need to mean the same thing in any context.

If this weren’t the case, no two RDF documents could ever be merged because you would never know if the authors intended their nodes to denote the same thing. But, like it was pointed out, it’s not necessarily a problem if this doesn’t occur in practice.

I think when it doesnt happen in practice it's because the people doing the merging know something of the context under which the document is written. You need this anyway - otherwise how do you know that the author of the RDF graph is a reliable source, or even competent in RDF?

Besides - I think this problem does happen in practice.

Re: URIs make metadata complicated

Phil Dawes — Thu, 22 Sep 2005 02:56:58 -0000

Joshua Tauberer writes:

> using URIs collaboratively and successfully requires a non-trivial amount of upfront thought, documentation and proactive consensus building.

Every naming scheme is going to be like that, to some degree. Do URIs actually require more upfront thought than other schemes, though?

More than localized, context bound schemes - yes. E.g.

PhilDawes name "Phil Dawes"
PhilDawes email pdawes@users.sf.net

didn't require much thought, because it is bound to the scope of this blog comment. It's a bit throwaway, but you still understand what I mean to some degree because you understand something of the context under which I wrote it.

Re: Serendipity will build the semantic web

Phil Dawes — Fri, 23 Sep 2005 14:52:45 -0000

Chimezie writes:

Hello Phil, first (and off topic) I’m a big fan of your work. I wasn’t aware that that you were also the author of BicycleRepairMan (quite an impressive software package - a shame development on it halted).

Thanks - that's very flattering. Regarding BicycleRepairMan - it's just a case of too little time I'm afraid - BRM got to the point where I was getting diminishing returns from it and there was too much other interesting stuff to do (e.g. semantic web). It does surprise me that there aren't any other refactoring browser projects for python though.

Regarding disambiguating seperate terms for the same concept, I think this is less a problem with the scheme of identification (URIs) than it is with bad ontological modeling practice. This problem will always arise if those responsible for developing the defining vocabulary do not take advantage of existing vocabularies and start with a bottom-up approach.

I think this is where our worldviews differ.
My assumption is that for the semantic web to get critical mass, lay-people are going to need to be involved in authoring the data vocabularies (as a side effect of generating data).

I don't think that a system that requires high-quality vocabularies based on rigorous ontological modelling practice will get this critical mass, because the lay-people (e.g. the vast majority of people that run a websites today) won't have thexperience or motivation to get this right.

Note that I'm not bashing experienced modellers or ontological discipline - it's just that I don't think that this can be a requirement for publishing workable data on the semantic web.

Re: Django openid auth - first stab

Phil Dawes — Fri, 06 Jan 2006 12:42:03 -0000

Forgot to mention - the simplest way to test this is to use the example/server.py module from the python-openid package. Have updated the README in the file to reflect this.

Re: Django media-serving dev webserver

Phil Dawes — Sat, 07 Jan 2006 14:14:46 -0000

Oh cool - thanks!

Re: Django openid auth - first stab

Phil Dawes — Fri, 27 Jan 2006 06:02:11 -0000

Cool - thanks. I'll take a look

Re: External Internal Blogging Trial

Phil Dawes — Tue, 31 Jan 2006 10:51:33 -0000

No - that's a good idea. 'workfriendly' is lame, but neither me nor Dave could come up with a better one. (and Steve is getting all his posts aggregated).

'*' is an interesting solution, and it looks like it'll even be aggregated by technorati. I'll get this sorted later today.

Re: External Internal Blogging Trial

Phil Dawes — Tue, 31 Jan 2006 11:02:07 -0000

Still working on the comments btw - I think I'm going to write a hack that compares the comments feed with the main feed and trims comments to un-tagged posts.

Re: Testing the '*' tag

Phil Dawes — Tue, 31 Jan 2006 11:05:42 -0000

Cool - the rss does the right thing: <category>*<category>

Re: The 'meaning' of an identifier

Phil Dawes — Thu, 02 Mar 2006 10:28:14 -0000

Hi Tim!

What do we mean by an assertion being true?

Exactly that.

Consider http://www.whitehouse.gov/president/gwbbio.html
as an identifier. What assertions are true of it?

It depends on what the identifier denotes - i.e. 'means'. This is the connection I'm trying to make - the meaning of the identifier is the set of assertions that are true of it.

Does that make sense?

Re: Global identifier schemes don't scale

Phil Dawes — Thu, 09 Mar 2006 03:54:18 -0000

Hi Matt,

Sure - I agree that this is a better way of factoring the semantics, but my point is that I didn't write this. By leaving out the date I effectively lumped the time and other state variables (such as whether id:PhilDawes is wearing clothes) into the pool of ambiguity around the identifier.
This ambiguity makes it easy for others to use the same identifier inconsistently - not necessarily inconsistently with the original document, but inconsistently with each others interpretations. (It's a practical issue rather than a theoretical one).

The upshot is that you need to consider the context of the communication to determine what is actually being identified.

Re: Bicyclerepairman BazaarNG tree

Phil Dawes — Wed, 12 Apr 2006 05:28:49 -0000

Wierd, as the tarball is just created on the sourceforge server in a crontab:
<pre>


0 0 * * * cd /home/groups/b/bi/bicyclerepair/htdocs/bzr; tar -zcf bicyclerepair-nightly.tar.gz bicyclerepair

</pre>

I've just down downloaded it and it works ok for me on Linux. (i.e. I can unpack it, and bzr branch from it). Unfortunately I don't have windows to check on. Could it be a problem with unpacking the tarball on a non-unix OS?

Re: Solving the Bicyclerepairman 'you have to save before you query' problem

Phil Dawes — Tue, 02 May 2006 16:34:57 -0000

Hi Sam!

For something like TextMate you should be fine working from an in-memory buffer - in 99% certain TextMate’s plugins can access the entire file.

Actually I found the most inconvenient thing wasn't saving the buffer I was currently working on, but other ones I'd also made changes to. I'm hoping that a BRM TextMate plugin could just adopt the same strategy as above - i.e. save unsaved buffers into temporary #filename# files prior to invoking a query.

Re: The 'meaning' of an identifier

Phil Dawes — Thu, 11 May 2006 06:20:47 -0000

If I've understood you correctly, you're basically saying that nobody can really know the true 'meaning' of an identifier (i.e. what it identifies) apart from the owner/creator of that identifier?

I suspect it's worse than that - even the owner/creator modifies and refines their interpretation of the identifier in subtle ways wrt time and context of communication. You've got a whole bunch of dimensions in which the 'meaning' can vary, it's a wonder that anybody can know what anything means with a high degree of precision.

In reality we all have our own in-head models of what different words and identifiers mean under different circumstances, and for meaningful communication to take place these need to intersect appropriately between the parties within the context of the exchange. (and there probably needs to be a mechanism for negotiation of meaning, just as in human communication).

That's why I'm not convinced that trying to use URIs to identify abstract things is going to fly on a global scale. I think URIs imply a level of precision that doesn't exist in the messy real world (the implication being that you can use the URI in isolation to uniquely identify something without requiring the context of the communication).

They do however work nicely for uniquely identifying web resources because the meaning is grounded in the lookup mechanism that all parties share.

Re: Clustering triplestores

Phil Dawes — Tue, 20 Jun 2006 06:21:51 -0000

Cool - do you have links? (I wasn't able to google anything concrete)

Re: All roads lead to lisp?

Phil Dawes — Wed, 21 Jun 2006 12:58:58 -0000

Hi Tom!
'Practical Common Lisp' arrived today from amazon - although have already read a few chapters from the online version.

Re: All roads lead to lisp?

Phil Dawes — Thu, 22 Jun 2006 10:47:59 -0000

Agreed, but you've got to wonder if they've got a point.

(IIRC Erik Naggum took the prize for the most bitter/twisted/vindictive lisp weenie)

Re: lockrun - overrun protection for cron jobs

Phil Dawes — Fri, 23 Jun 2006 10:40:16 -0000

Sweet! Hadn't seen that - many thanks

Re: Lisp conditions - more powerful than exceptions

Phil Dawes — Tue, 27 Jun 2006 09:41:55 -0000

Hi James,

The caller knows what to do because it has requirements it wants to fulfill. If you want a parser that silently ignores the errors you write an exception handler that invokes the 'skip-line' restart. If you want to log you do that etc..

This problem is certainly solvable in other ways - you could implement an error callback, or maybe an abstract base class or strategy pattern or something. AFAICS the benefit of the condition system is that it's quick and easy to do the right thing upfront - you defer the error conditions to the caller, who is more likely to know what it wants to do and can change later.

E.g. If I'm writing a parse function in python/java I don't think 'this should be an abstract base class because I might want to reuse it in other circumstances later' - I just write and test the function (simplest thing).
Then when the program wants to ignore unparseable lines I might add a flag-argument to the function. Finally I might refactor it into a class structure later when I need to use it in other systems.
With conditions I just add the resume points to the function - the refactoring is small and idiomatic.

(btw, it's early days for me and common lisp, so I don't have any practical experience of how well this works)

Re: Understood vs Learnt

Phil Dawes — Tue, 11 Jul 2006 04:58:29 -0000

To be honest I haven't needed to try stuff much - the answers are pretty easy to follow and it's usually the underlying pattern or concept that's important rather than seeing running code.
(and I understand that the original little LISPer book was written using an un-implemented dialect of lisp - can anybody confirm/deny?)

That said, I've been playing with gambit, bigloo and sisc (scheme in java) a bit recently.
Gambit is especially interesting to me because of the parallel computing possibilities of termite. (I never really got on very well with erlang's syntax)

Re: Understood vs Learnt

Phil Dawes — Tue, 11 Jul 2006 05:01:33 -0000

btw, the termite homepage is here

Re: Application UIs - automating the CRUD

Phil Dawes — Mon, 17 Jul 2006 07:40:20 -0000

Hi Alex,

I watched the demo (which I think cropped a bit - it finished just as you were getting to the wrapped fogbugz database). The schema metadata is pretty much what I was thinking of, although a rich GUI that can be given to users is the big win from the perspective of the post. I'd be interested to see what you can construct from the metadata in this regard.

(Unfortunately I didn't actually try the software because I don't run windows, but I'm definitely interested in the approach!)

Re: Application UIs - automating the CRUD

Phil Dawes — Mon, 31 Jul 2006 09:01:20 -0000

Hi Dom,

Only if the app is only ever used by techies for low transaction volumes then you might consider putting the UI into production.

I can see what you're getting at, but I don't think I agree. I'm not saying that any application is a suitable candidate for a generic rdb mapped UI, but I'd say that the sweet spot is pretty big even with just a small amount of sophistication in the mapping.
Assuming the web as the deployment platform, people are already used to using pretty basic (and generic) UI widgets and layouts for entering and manipulating data.

Also, why low transaction volumes? - I'd argue that transactional volumes don't have much bearing on UI design - more on the actual data modelling and access patterns, which you'd be doing with an RDB anyway. (or have I mis-understood something?)

Re: Application UIs - automating the CRUD

Phil Dawes — Mon, 31 Jul 2006 10:08:54 -0000

Ah -ok. I was thinking of high transaction volumes from a server perspective rather than in terms of individual productivity.

This is an interesting point; My day consists of using a small number of desktop UIs constantly (email, unix console, emacs, browser), and a whole load of other intranet web based UIs infrequently (low 10s of times a day)?
How does this tally with others? Is there a trend to using more interfaces less frequently as the repetitive tasks get automated?

(I should also mention that django does provide some ui hints aimed at productivity - e.g. you can nominate to inline child objects with their parents, display a variable number of empty ones for quicker entry etc.)

Re: Orange Juice on my laptop

Phil Dawes — Tue, 01 Aug 2006 07:12:26 -0000

Yep, although some of the keys stopped working after a while so a bit of keyboard re-mapping was in order.

Re: Laptop resilience

Phil Dawes — Tue, 01 Aug 2006 07:22:49 -0000

The resilience of laptops never ceases to amaze me.

To qualify this: I have a bit of experience when it comes to mistreating laptops; I dropped my sony x505 down the stairs a few years back (carpetted stairs mind you, but it still bounced 3 times without breaking). My last work laptop got nicked. Then there was the orange juice incident.

Re: Java cage rattling

Phil Dawes — Thu, 10 Aug 2006 11:06:37 -0000

pure “Java programmers” are only a step up from VB weenies ;-) and many have no concept of functional languages except that “they’re a bit hard to write in”

Blimey - if that's not a troll I don't know what is!

Re: Amazon get into the virtual computing space

Phil Dawes — Fri, 01 Sep 2006 04:23:51 -0000

Sort of - however the Sun grid offering is targetted and priced for traditional enterprise clients and established industries who want to bolster their number-crunching horsepower (see faq). I think this is a bit before it's time - enterprise still hasn't got used to the idea of taking data out of its own intranet.

I think the interesting thing about amazon's offering is that it is clearly priced and targetted at the low end of the market. This is the sector I think will push demand for service grid technologies in the same way it has for cheap web hosting: individuals and startups wanting to start small but then needing to scale up close to the demand curve (rather than risking VC upfront for their server facilities).

Re: Scheme is love

Phil Dawes — Thu, 21 Sep 2006 07:19:25 -0000

Yep, I've done the Gambit... no Chicken!.. no Gambit!... etc.. shuffle.

I've settled on gambit for the moment because of termite. I'm hoping that the new library system in the upcoming r6rs standard will lead to more portable set of libraries and make the choice less all-or-nothing.

Re learning a new language: I think you're right to be nervous. The biggest problem is the Red Pill-ness of it all. Once you've hit upon a feature you like, especially one which gives a big productivity boost, going back to your old language is pretty depressing. I remember in the late nineties witnessing a bunch of jaded smalltalkers hit the java market - they had this constant 'things will never be the same' look about them.

Re: Scheme is love

Phil Dawes — Mon, 25 Sep 2006 16:39:03 -0000

Cool - I'll check it out. Thanks

Re: Dark side of the semantic web

Phil Dawes — Tue, 19 Dec 2006 09:52:53 -0000

Hi Josh, I think you're missing something here: the only way you can ever be 100% sure that two documents are talking about the exactly the same thing is through shared knowledge about the context and provenance of the documents. Nothing stops somebody from inadvertantly using a URI to mean something slightly different to the original author.

In the foaf case you're relying on the client to have understood that 'http://xmlns.com/foaf/0.1/mbox' is an IFP property requiring a unique personal mailbox and not one e.g. shared with a spouse. So we're talking about sliding scales of confidence here, not absolutes.

Using a description framework ala RDF allows you to disambigate terms through their relationship to other terms. This is a proven technique in natural language and translates well to software: Applications have knowledge of the problem domain they're operating in and the combination of terms they're expecting to operate with. That combination of terms provides a trivial way to disambiguate data from disperate sources. Besides, you can always add disambiguation metadata to your descriptions:
<pre>


<> type FoafPerson
<> usesTermsFrom http://www.foaf-project.org/
<> name "Phil Dawes"
<> surname "Dawes"
<> homepage http://www.phildawes.net/
<> mbox phil@example.com

</pre>

Also you tend to find that where there are global areas of ambiguity humans tend to invent names and schemes which have a low chance of collision. Email addresses, vehicle number plates, URLs and names like 'FOAF' are examples of these. These are already grounded in real life, widely shared, and are ripe for use in data exchange.

Re: Microsoft to support OpenID

Phil Dawes — Wed, 07 Feb 2007 07:51:44 -0000

Ah - looks like you've been bitten by the 'comment not showing up because it's queued for moderation' trick.
(I had to turn on moderation - too much spam was slipping through and adverts for viagra don't look too good on the internal company blog aggregator)

Re: Microsoft to support OpenID

Phil Dawes — Wed, 07 Feb 2007 12:38:24 -0000

But if I delete it, my comment won't make sense and I'll look like a tit!

I think my comment system does the same for vanilla comments, but I'm guessing the openid plugin must be incompatible somehow.

Re: Multithreading links

Phil Dawes — Fri, 23 Feb 2007 04:26:26 -0000

Oops! - thanks. (fixed now)

Re: Some ideas for static triple indexing

Phil Dawes — Tue, 01 May 2007 03:13:37 -0000

Hi Drew,

The latter. Subject identifiers aren't exposed to the client so there's no way to make statements using them specificially. Instead to join data from two subjects in different graphs you must use identity by discription (i.e. the subject that has these property values..) and the person/agent doing the query must know about them.
Internally the subject IDs can be in the 'object' position to support things like containment. E.g. the XML:

<pre>


<person>
  <name>Phil Dawes</name>
  <email>phil@example.com</email>
  <knows>
     <person> 
         <name>Steve</name>
         <email>s@example.com</email>
     </person>
  </knows>
</person>

</pre>

Internally indexed as:
<pre>


#1 name "Phil Dawes"
#1 tag Person
#1 knows #2
#2 name Steve
#2 email steve@example.com
#2 tag Person

</pre>

but externally you can't refer to them. Does that make sense?

Re: Some ideas for static triple indexing

Phil Dawes — Tue, 01 May 2007 03:15:27 -0000

Hi Nick,

Opaque subject identifiers are even easier to index because they can be picked to be sequential in the index. I.e. subject 3 is at position 3.

Re. number of indexes: I think I'll need at least the following.

s->p->o
p->o->s
o->s->p

So 3 index hierarchies for searches. The subject-id-in-the-object-position mentioned above is a special case, and will probably require its own (relatively small) index o->sp.

Re: London Haskell User Group

Phil Dawes — Wed, 02 May 2007 10:04:02 -0000

Oops sorry! Corrected.

Re: A simple scheme unittest DSL

Phil Dawes — Thu, 24 May 2007 06:49:41 -0000

Hi Nat,

Actually using continuations was the original plan but it turned out to be more tricky than I'd expected because of syntax-rules macro hygiene.

The problem is that the inner assert macro can't just use the symbol for the continuation because it gets masked, so IIRC the outer macro needs to traverse the code re-writing the assert calls to include the continuation as an argument - it was doing that where I came a bit unstuck and switched to the exception hack.
Hmmm... maybe I should revisit this.

Re: Indexes, Hashes & Compression

Phil Dawes — Fri, 27 Jul 2007 05:27:34 -0000

@pigalle: thanks for the comments - I'll take a look at reiser4.
The ~10ms latency is for a disk seek not a read. What sort of timings are you getting?

@Seth: Cool - I'm planning on doing the same thing (have you read the research papers for cstore?).

Re: Coding when you're tired and unmotivated

Phil Dawes — Mon, 30 Jul 2007 06:27:03 -0000

Hi Arto,

That's good advice. All my projects until recently have been shared and so I've had a cvs or svn repository to work with.
I assumed that this one wouldn't attract any other coders (given that it's written in gambit scheme), but hadn't thought about just using a repository anyway. Time to crank up git.

Cheers!

Re: More factor: tabular to triples

Phil Dawes — Sat, 13 Oct 2007 15:32:33 -0000

Thanks Christopher - it was a missing close brace in the factor link preventing it from being displayed.
I'll definitely check out both Cat and ripple - thanks for the links

Re: W3C Semantic Web = Global Ontology after all?

Phil Dawes — Thu, 13 Dec 2007 04:43:51 -0000

That's true, but for semantic interoperability the same URIs need to feature in the communication somewhere - whether directly or via relationships defined in owl.

Re: Beginning Factor is like programming assembler

Phil Dawes — Thu, 13 Mar 2008 05:23:54 -0000

Hi Manu,

The factor cookbook started me off, but the thing I found really good was Leo Brodie's "Thinking Forth" Book, which helped convince me that time spent learning a stack language wasn't a waste of time.

Re: Beginning Factor is like programming assembler

Phil Dawes — Thu, 13 Mar 2008 09:22:51 -0000

hmmm.. I think you're right. Maybe I should elaborate in another post. In the meantime I suspect the factor mailing list is littered with examples. Here's a recent one.

Re: Digging into Factor's compiler

Phil Dawes — Wed, 09 Apr 2008 01:39:16 -0000

Thanks Slava. I need to fiddle with the CSS but have got to go to work now. Have turned it into a blockquote in the meantime...

Re: How realistic is using OWL for semweb data integration?

Phil Dawes — Fri, 11 Apr 2008 10:31:56 -0000

Hi Bob,

Thanks for the reply.
I suspect the devil is in the detail. For example how would you map RSS1.0's item 'description' and Atom's entry 'content'?. The former is a literal property but the latter is structured object.

Re: How realistic is using OWL for semweb data integration?

Phil Dawes — Fri, 11 Apr 2008 10:51:13 -0000

Sorry I didn't make that very clear. I meant the rdf for rss1description is:
<pre>
#item1 rss1:description "foobah"
</pre>
whereas the atom RDF for content would be something like :
<pre>
#entry1 atom:content #content1
#content1 atom:type "xhtml"
#content1 atom:value "foobah"
</pre>
Does that make sense?

Re: Searching arrays in X86 assembler with a bloom filter pt 2

Phil Dawes — Fri, 12 Sep 2008 06:33:13 -0000

Hi Kieran! I'm expecting thousands occasionally. Hundreds commonly.

Re: Searching arrays in X86 assembler with a bloom filter pt 2

Phil Dawes — Fri, 12 Sep 2008 09:21:58 -0000

Thanks for the tip Asm. It seems pretty quick but I'll try the ANDing and SHRing approach to see how it compares

Re: Searching arrays in X86 assembler with a bloom filter pt 3

Phil Dawes — Sat, 13 Sep 2008 06:29:11 -0000

@Asm - thanks for the link, that's a handy resource

Re: Searching arrays in X86 assembler with a bloom filter pt 3

Phil Dawes — Sat, 13 Sep 2008 06:30:13 -0000

Slava Pestov wrote:
> Hi Phil,
>
> I couldn't post a comment on your blog for some reason so I'm posting
> this to the list instead.
>
> The seq>hash word you write already exists in the sets vocabulary, its
> called unique.
>
> And (prepare-filter) looks nicer if you use fry:
>
> : (prepare-filter) ( filter seq -- )
> '[ 1048576 mod _ set-bit ] each ;
>
> Slava