Worth looking at if you haven’t already.

Artist:(.Album.ReleaseDate.Year:=1984)

or, because all the relationships go both ways, you could find out the same thing in any of these ways:

Album:(.ReleaseDate.Year:=1984).Artist
ReleaseDate:(.Year:=1984).Album.Artist
Year:=1984.ReleaseDate.Album.Artist

But if you wanted to find only artists who had albums that were released in the US in 1984, you’d instead do one of these:

Artist:(.Album.ReleaseDate:(.Country:=USA):(.Year:=1984))
Album:(.ReleaseDate:(.Country:=USA):(.Year:=1984)).Artist
ReleaseDate:(.Country:=USA):(.Year:=1984).Album.Artist
Year:=1984.ReleaseDate:(.Country:=USA).Album.Artist
Country:=USA.ReleaseDate:(.Year:=1984).Album.Artist

As for finding the right Nirvana, that’s also a data issue, not a query-language issue. You can refer to things by ID in Thread, too, so “@nirvana_us” is a complete Thread query to find the node with that known ID. Or you could find them by whatever other criteria you’d use in any other system, like:

Artist:=Nirvana:(.Member:@cobain_kurt)
Artist:=Nirvana:(.Album:=Nevermind)

Also how will you deal with ambiguity such as detecting which group called Nirvana was intended in an Artist query? Artist names don’t generally have a normalised form and if your database doesn’t contain the year of formation or home country then it’s going to give some strange results.

The traversal parts etc seem pretty trivial to overlay on a triple store. I recently implemented the Fresnel Selector Language in PHP which has some similarities (see http://www.w3.org/2005/04/fresnel-info/fsl/ and http://code.google.com/p/moriarty/source/browse/trunk/graphpath.class.php )

1. Thread nodes “have” literals, whereas in RDF nodes are connected to literals by predicates. This allows a Thread query to say, for example, “Year:=1984″. But this could already be written out more explicitly as “Year:(.Name:=1984)”, so this point is just about brevity in queries, and could be solved by mapping some common “name”-ish predicates to the syntactic shorthand. Minor.

2. In Thread data all relationships are asserted and maintained in both directions. Thus you can ask “Artist:(.Album.Year:=1984)” to find out all the bands who put out albums in 1984, and you don’t have to worry about whether the relationship from Black Sabbath to Sabotage was explicitly asserted as “black_sabbath album sabotage .” or “sabotage artist black_sabbath .”. So you need to get those inverses all either asserted or inferred, either at data-modification-time or query-time, to make sure you’re not missing anything in query-evaluation. Not a conceptual problem, but if it’s going to be solved with inferrence, the RDF data would have to include the appropriate owl:inverse statements, at least, and I don’t usually see those in published RDF examples.

3. Thread’s data is expressed directly in nodes, with each node’s internal data-structure including all its outbound arcs/predicates, whereas RDF implies nodes via decomposed triples. Thus most traversal operations are fast in Thread more or less by definition, and would tend to be slow or impractical if each step of query-evaluation had to rescan the entire universe of triples to re-infer the “nodes”. But this is just a matter of pre-indexing, and/or convention. The N3 notation in your examples is basically this same idea: bundle together all the statements about each node. And I suspect many RDF query-engines build indices by node-ID as preprocessing already.

Logistically speaking, the production system for which Thread was designed is a data-aggregation/analysis/republishing platform being built at ITA Software in Cambridge, MA. It’s in private beta-testing now, and I’m hoping to have at least a small public database available for query-language demonstration ahead of public exposure of the whole system, hopefully within a small number of months…

SPARQL is not good enough. The human question here is, given a sparse set of date-observations, what is the pair before and after a given date known to be in the middle. Your SPARQL query takes 14 lines to express this (plus six prefixes!), and would be even uglier if it weren’t for the semantically dubious (and anti-open-world-assumption) intervalAfter/intervalBefore relationships you added to the data itself.

I submit that a good query language would let you ask this question in some way much more like this:

@anon.Residence#RecordYear::?,RecordYear1874,?

And, for that matter, what you’d really like here in a more general sense is a list of the person’s residences, sorted by temporal proximity to the year in question, subsorted by year. That’s a better question, because it can be answered whether the year is before, during or after whatever data you have. Is that doable in SPARQL? Via CONSTRUCT, somehow? But it should be even easier to ask than the previous question, something more like this:

@anon.Residence#(.RecordYear._–1874),Year

I have a blog post about this query-language, if you’re at all intrigued:

http://www.furia.com/page.cgi?type=log&id=324