Mandelflakes!

Mandelflakes!

The Mandelbulb is a rather stunning 3D fractal. While it's not exactly a "3D Mandelbrot set", it uses the same computational trick of choosing a point in space, then repeatedly applying a transformation to that point and observing whether it stays close to its point of origin or flies away in annoyance.  Those points which stick around are considered to be part of the set, while those that fly away are not.  The Mandelbulb formula transforms points in 3-space, and therefore defines 3-dimensional sets of points.  There are an infinite number of Mandelbulb sets: one for every real-valued "power", a parameter which affects the symmetry of the set. Most of these are very intricate and bizarre-looking objects.  Even 2D slices of a Mandelbulb set can be pretty interesting, as I learned while playing with raster/voxel Bulbs in the AMIDE medical imaging application (see Dave Gilbert's page, Fun with Mandelbulbs and 3D printers, for background).  For example, if you slice a Mandelbulb with a power of 7.0 along its axis of symmetry, the slices look like a bit like snowflakes, which is what you see above.  Click here for a larger view.

RDF/JSON support for Sesame

I invested a few of my scant daylight hours today in an RDF/JSON library for Sesame. Sesame being the RDF toolkit from Aduna, and RDF/JSON being a proposed serialization format for RDF.  RDF/JSON is more compact and easier for a human to read than RDF/XML, but it doesn't require a specialized parser like Turtle or TriG do.  Good for easily mashing RDF data in JavaScript or the like.  Anyway, Hannes Ebner had already written some code to parse and serialize RDF/JSON in Sesame, to which I added RDFParser and RDFWriter implementations so you can register the format with Rio and make it accessible to existing tools.  I also added Named Graphs as array properties support as well as some regression tests.  Code's here, API docs are here.

Your favorite graph DB as a triple store

Some of the oldest and most scalable RDF triple stores are backed by relational databases.  It's a good way to avoid reinventing the many wheels of storage structures, transactions, caching and so on, and focus on the unique features of RDF.

BlueprintsSail on...However, the relational data model is not particularly well-suited to the sparse graph structure of typical Semantic Web data.  Relational table joins make less sense for SPARQL query answering than they do for dense tabular data, and they make even less sense in applications which are heavy on graph traversal.

Well, what about graph databases? These are built from the ground up to work with graph data.  At least one, AllegroGraph, has triple store functionality built in, while the rest require an adapter of some kind. Fellow TinkerPopper Marko Rodriguez and I helped to develop one for Neo4j.

The Blueprints graph interface, though, offers a new possibility: a single RDF storage and query layer which interoperates with any number of graph databases.  Blueprints includes a minimalist vertices-and-edges data model which is rapidly being taken up by the developers of some of the most popular NoSQL databases.  OrientDB and Neo4j adapters already exist; a Redis adapter is soon to be merged in, and others for InfiniteGraph and the DEX graph database are under development.  In theory, an RDF layer on top of Blueprints will allow any of these to be used as a persistent RDF triple store.

That layer now exists as BlueprintsSail.  As an implementation of Sesame's storage and inference layer (Sail) interface, BlueprintsSail allows you to connect any Sesame-compatible tool, such as a SPARQL endpoint, a Linked Data crawler, various Semantic Web reasoners, and so on, to any Blueprints-compatible graph database.  You can alternately treat the data as RDF statements or as a native graph in Blueprints or the back-end store's own data model.

BlueprintsSail uses a hybrid index-based and graph-based statement matching strategy for query answering. It is available as a development prototype on my GitHub and will be merged into the next (0.4) release of Blueprints.  The JavaDocs are available here.

Where are all the Named Graphs?

What if you could translate human knowledge about every conceivable topic into machine-friendly formats and link it all together in a Giant Global Graph?  The Linking Open Data project is doing just that: social data, government data, academic data, data about products, music and movies, and so on, are all finding their way into the cloud.  However, if you stare at this data for long enough, you might notice that it lacks a basic dimension of human knowledge: intention.  A person can easily express the fact that x is true today without implying that it will still be true tomorrow, or that John told me x, giving John credit for the information while disclaiming any responsibility for its accuracy... all of which helps us, the information consumers, to decide which information to accept and act upon.
 
In fact, this is possible on the Semantic Web by means of an extension to the RDF data model, called Named Graphs, which allows providers of Semantic Web data to qualify it with arbitrary metadata.  While much has been said about the potential of Named Graphs to support provenance and trust, there are no clear guidelines that I am aware of for their use in Linked Data.  I was curious about any solutions which the various data providers may have come up with, so I decided to go hunting for Named Graphs in the 2010 Billion Triples Challenge (BTC) data set.
 
To be clear, in the following I am only looking for Named Graphs as proposed by Carroll et al. -- that is, rdfg:Graph's -- but I might as well mention a few other things with a label of "graph" or "Graph":

Random thoughts in 141 characters or more

 

I don't blog much.  However, I do tweet a lot.  At least, I did before I moved to China, where the Great Firewall takes some of the fun out of it.  Twitter is great for bookmarking random thoughts and sharing them with the world, but occasionally 140 characters just aren't enough.  This blog is for those other occasions.  

To begin with something literally random, here is a field of pseudorandom dots in two different "styles": messy and neat.

messy and neat dots

I had noticed that in pointillist drawings, different collision avoidance strategies lead to different visual effects.  And, well, I wanted an excuse to play with Processing again.  The code allows you to "pointillize" grayscale images and is available on GitHub.
Syndicate content