Let's say I have something named/identified with a URI, like myself, now everytime that's mentioned anywhere on the web I'd like to know about it (okay not all the time, but it should at least be possible) - insert multiple scenario's here, conclude that any notification solution needs to be as generalized as possible.

So, I simply propose 3 basic things:

NOTIFY - a new HTTP verb

Why a new verb? to prevent collisions with usage of POST and to leverage the already existing design of HTTP, especially things like Accept and OPTIONS. (will need to have properties similar to POST)

notify - a new link relation

To be used in html, and with the Link header, this allows resources to specify where notifications should be sent to.

x:notify - a URI identifying the new link relation

it's just the rel, but using a full URI for compatibility with the semantic web.

That's it, quite sure one can build a lot of things on top of that.

a) The web is currently converging around web applications and mobile devices, a lot of focus is being placed on sensor networks, internet of things, and augmented reality to display information. Simply, how can these applications make use of published data readily from multiple sources if that data is not in a uniform standard?

b) The core web which people use on a daily basis is ever more silo focussed, and the size of those silo's is ever increasing - the social sector is a great example of this, and whilst there are core movements to create a more federated and distributed social web, a key blockage in the way is a lack of uniform data, often new formats are being developed, or poorly modelled application (rather than domain) specific models are making it out on to the web, and interoperability is several times harder than it could be, given the presence of uniform data. This has significant social and economic repercussions.

c) Time, a significant amount of time is invested daily by thousands (if not millions) in to re-solving the same old problems, creating a schema for this, a model for that, learning the same lessons countless people have learned before them, often the learning curve spans several years. A standard way to publish and share reusable model specific schemas (/not/ format specific like XML schema and JSON schema) would save vast amounts of developer time per annum. In addition to having significant economic impacts this would also lend to far more innovation (since more time free to innovate!) within an already important and innovative sector.

Why not "plain" RDF?

RDF has failed to be understood, adopted or loved by the general masses of the web, even many who use RDF often do not fully understand it and have many issues. Adoption has been... let's just say not good.

There are 3196 APIs on ProgrammableWeb, out of those:

• 2152 produce XML
• 1255 produce JSON
• 36 produce RDF

Perhaps more indicative though, is that those 36 are spread over 6 years, with only 1 updated so far this year, meanwhile there have been 58 new JSON based APIs in the last month alone.

Over on stack overflow, there have been 1,569,512 questions asked, 273 that's 0.017% of them, are RDF related.

The numbers are pretty clear, for all RDF's merits, and the countless benefits of the uniformity of RDF, it's just not being adopted.

To use RDF correctly requires RDF tooling, and not just tooling to parse the data (like JSON, and common usage of XML), but to use the data, to handle triples and graphs and queries, all of which requires significant investment in skills, time, and deployable technologies.

Further more, RDF data published using multiple different ontologies is difficult for people to use, the infrastructure and tooling simply doesn't exist to follow ones nose around the web and make practical use of several thousand different ontologies, that level of understanding is a good generation away, and for now all it does is serve as a blockage to adoption, and primarily as a blockage to people actually using or presenting the data. Time and time again we have seen a rallying around core ontologies, with successful mixing and matching happening more at the ontology level, than the data level. For now applications will be looking for mentions of Classes and Properties they "understand" (have a hard coded usage for).

Additionally, these difficulties in usage have lead to a second layer of centralization on the web, one which was borne from RDF, and rather ironically many of the architectural benefits of uniformity and universality are being lost. That is SPARQL, we are seeing a huge increase in SPARQL enabled datastores on the web, each of which holds a specific set of data, and each of which has key resource limitations. Practically this means that:
- clients are tightly coupled to servers
- all processing and storage weight is being handled by the servers
- data on the wire is non uniform
- clients are not using the web of data, rather they are using a datasource on the web, a datasilo.
This is a pattern which is not optimized for anybody, servers, clients, developers, data, the web, the network.

The core benefits of a web of linked data have not realized, RDF has failed to deliver them, primarily due to complexity and tooling requirements. SPARQL (positioned on the server/silo) is only compounding matters. That's not to say it cannot deliver them, or that these technologies are bad, only that they have not delivered the core benefits, yet.

Perhaps another way to put it, is that if you break things like RDBMS and Classes and Objects down you can get to triples of some sort (EAV, RDF, or to atomic relations / predicate based logic), and RDF did just this, however it was done in such a way that the data format (RDF) required a full new stack of technologies to /use/ the data, rather than being a uniform data format acting as a bridge between say classes and objects and RDBMS, a webized data model; that is to say, you can't really use "it" (RDF, the model people don't really speak of) with 95% of the deployed technology out there, you can provide an RDF view of the data from that technology, map it to RDF, but you cannot easily pull it back in and use it, and unusable data, isn't much use. There are many shades of grey between, but it's certainly more at the unusable end of the spectrum.

What can we do?

If we look at what people already do, a large proportion of web developers (most) continue to publish data via web services as XML and JSON, the common process is simple, create a schema, document it somewhere out of band (perhaps call it API documentation), publish data using that schema in some arbitrary way as XML and JSON. On the client side the same process continues, find a new API, get an XML or JSON parser, map the data as described by the API to some classes and start using it. All of this is needless work, they are showing us what works, what they can do, and how they can work with data easily. Tersely, they are missing the benefits of Uniform Data.

We can bring the benefits of uniform data to the current web 2.0, class and objects, rdbms, xml and json focussed web.

We can not only address these core issues, and bring the benefits of linked data and the semantic web to the general developer population, but we can also:
- ensure it's RDF and traditional semantic web compatible (giving "us" mountains of useful every-day data)
- provide that clear migration path to the "full" semantic web that's missing now.
- increase semantic web adoption exponentially, bringing big benefits without the high cost.

Approaches

There are two key approaches I can personally see to this:

1. Webize Classes and Objects (Java style POJOs, Data Objects, subset of UML)
2. Provide a Classes and Objects view over RDF

The first of these approaches - providing an abstract syntax for classes and objects and then defining mappings for that to XML and JSON - would bring the benefits of OWL 2 and XSD to schemas, and the benefits of "linked data" to both the schemas (/class blueprints) and instance data. It would allow data validation rules to be augmented on from sources external to the schema, it could be codified in libraries across multiple languages, it could also serve as a translation layer between Classes and Objects, NoSQL, and RDBMS, and other formats such as CSV. Additionally it would lend each schema openly being mapped to vendor specific databases, as well as vendor neutral schemas such as ANSI SQL. Furthermore, it would also lend to innovation in each layer, for example standardized queries for each kind of data could be created, with translations of those to each specific vendor or to well defined standardized languages, and even codified to work in memory in libraries (for example within instance methods or to run on GPU enabled hardware and languages). Many benefits could come from webizing what the masses already do. Other examples include providing an opportunity to refine the core datatypes on the web in a serialization agnostic way (think xsd types merged with webidl types), ensuring the correct entailments for equality are baked in to the core, providing first level support for things like lists and sets, providing a foundation upon which diff, patch, versioning can all be accomplished, providing canonicalized forms so that encryption and a data signing can be accomplished... and more I'm sure.

The second of these approaches has less wide scale benefits, but would provide a more usable abstraction layer on top of RDF, which is currently (dare I say painfully) missing. This would ultimately make working with data more familiar, a codified example could be:

var person = new Class('foaf:Person');      // external class definitions loaded from the web
person.load('http://example.org/bob#me');   // instance data loaded
print(person.name);                         // simple access to pre-known properties
person.validate();                          // in built validation from OWL 2
                                            // and XSD data type restrictions

// work with a schema class at a time..

var man = new Class('gender:Male');         // different class for different data
man.load('http://example.org/bob#me');      // same data
print(man.wife);                            // different, domain specific properties
man.expand();                               // full entailment regimes support to get
                                            // the most from schema definitions 

The best approach will become clear as time progresses, for now I'm keen and happy to work on either or both.

Just some musings..

A side effect of this, is that it let's me sit back and look at the country in which I live. The UK (or Great Britain, or whatever you call it). You probably know what I'm about to say, but I don't see anybody else saying it - granted, I haven't looked, but the way I see it is, if this isn't coming through my social stream then it isn't being said - so let me say it.

If the UK was embodied in a person, it would be a desensitized homeless addict without any morals, who'd taken advantage of and harmed every person they knew, and that was currently in mid air, about to hit the ground, after jumping off a bridge. I'm probably being too kind there though. From here on, this post is just going to be a collection of fragment paragraphs which hopefully illustrates.

Japan has just been hit by so many disasters it's unreal - I can say without a shadow of a doubt though, that if they had happened in the UK the effect would have been several orders of magnitude more devastating. The infrastructure would have crumbled, there would have been next to no warning bar the web's social media streams (that is to say, I'd probably have had to run down the street and warn the neighbours as they wouldn't have had a clue), the death toll would have been unimaginable. The response? can you really see our government (country wide or local) doing anything to respond that amounted to anything of consequence? Do you think there's a plan for any such event (of any kind on a similar scale), do you think there's even a plan, a clue, any preparedness at all? Can you see our prime minister stepping up to the plate and doing anything other than hide or squirm? Let's not gloss over things here, we would be completely and utterly screwed.

The middle east, uprisings everywhere, the people have a drive and are prepared to at least try and do something. Now, can you see that happening here? our economy is gone, there are no jobs, people are being made redundant at a scary rate with no more jobs for them to walk in to. The country produces nothing, has no industries, there are no jobs for our children, well over half the population is paid out of the tax of the other half of the population, and the half that pays the taxes are dropping like flies and struggling for work or to make a wage. Here's the horrible bit though, some of the people who are out of work just accept it and do nothing, others work themselves to death (literally, I knew several people did everything they could to provide for their families after loosing their careers, and sadly are no longer with us, overwork and over stress, they just died, unceremoniously at a young age - really good men, the best kind), yet others are busy scraping themselves through life and in to early grave. Some, the over 40s are just without hope, there's nothing for them now, they had a career and were the foundations of the companies and organizations they worked in, they have nothing now, can't get any kind of job doing what they did (even though the country needs their skills!), they can wallow or possibly get unskilled work, they can kiss goodbye to their pensions though, nothing to look forward to there, if they're lucky they've already bought their homes and can.. oh wait, no housing market is gone and they don't have a job, probably have to sell their homes just to survive and go live in a small flat somewhere, scrap that thought. The other horrible bit? the rest of the country who are working, are too distracted by a combination of money, stress and distractions (tv, material goods, fake lives, striving after the wind) to do or say anything about it, they just get on with their own lives until it happens to them and then nobody listens because they're too distracted with (repeat). The nation is too demotivated to do anything frankly. Ahh but these other countries are full of corrupt people stealing their money and wasting it.. yes, and we've legalized that process and made it law, the norm. What percentage of your wages goes to tax and national insurance? then what percentage get's taxed on everything you spend - do the maths, take a wage of an easy figure, say £1000 GBP, take off the tax and national insurance, then the spend the rest and take off the amount of that which is taxed, then pay one other person with what's left that wasn't taxed and repeat. How much is left after two circulations through the economy? what percentage of that money was trimmed off as tax? almost all of it. It makes you wonder how the country even functions. So where does that money go? in to our crumbling infrastructure? schooling? health? general services? No chance in hell, there is no way that much money can produce that little results - it just does not add up, especially when you couple that to the debt we have as a country.

I spoke to a taxi driver last night, he owns the business, it's his retirement you see and the only way he can actually do any work and make a living, a skilled worker all his life, that's all he's got left now, and he's one of the lucky ones, anyway, he told me that the night before he'd picked up a local bank manager, a bit tipsy (drunk that is), who said that he doesn't think he can do his job any longer, because he sold mortgages to a load of people because they wanted new build properties in a nice area of town, now not one of them (in the entire scheme) can handle the mortgage payments, some of them are homeless, a couple of them have recently committed suicide, he feels guilty because he saw it coming. It all interconnects, this guy who owns the taxi company has a new driver called Mo. Mo is a few years older than me and has two young children, he works two jobs, starts one at 8am (the telesales job, although Mo is a qualified computer/network engineer and mathematician) and finishes driving the taxi at 3am, 6 or 7 days a week, he's working himself in to an early grave, but has no choice. Mo recently joined that company, because two weeks before the company he previously worked for was put up for sale (£50k price tag), Mo wanted to buy it but the bank said no, and nobody else around to help him, so he's stuck. The company was put up for sale by the previous owners widow, because her husband, who I also knew, was working two jobs, the taxi business and working on the oil rigs, he was a brilliant man, kindly man in his late 30s - dropped down dead from overwork and stress last year, he dropped me off down the street, went home picked up his equipment for the oil rig job, drove to the airport, went to step on the helicopter and dropped dead from a heart attack. That you see is why his widow was selling the business, why Mo had to leave to this other company, and how I came to be speaking to the taxi driver at the start of this paragraph last night (because I wanted to give Mo my business, but Mo wasn't on). Coincidently, the other driver who's having to leave, Bill, is awaiting retirements to go and live with his wife in Taiwan, he can't leave the country yet because he won't get his full pension if he does, so he's stuck here twiddling his thumbs for a couple of years first, with no work of course even though he's incredibly skilled at what he does. Ahh yes, and the company that's getting sold, well that's just been bought, by somebody who's just been made redundant from the local council and can't get another job, it was literally, his only choice, because he has to pay for private health care for his wife who's ill and needs an operation for which the waiting list is years. I find that all quite sad, these are just the normal people I see on a daily basis.

I'll stop there I think, and get back to my web bubble where I can work, can communicate, and do get to see at least some of what's happening in the world, I'm protected in a way I guess. I do feel guilty for that protection though, when my friends who I grew up with, who have traditional trades, are all pretty much screwed.

The problem though, is that I have kids, so what do I do to guarantee them, at least a fighting chance, a job, and maybe a place where priorities are a little more in order (like a formerly third world country perhaps)?

• a URI is associated with a thing by a group of agents/people as a name for that thing.
• some URIs are also associated with a set of representations over time by the dereferencing process.

Why were the representations made available for that URI?

• because somebody made a web page and then needed a uri to refer to it.
• because somebody named something with a uri and then wanted to provide information about it.
• because somebody made a web page about one specific thing and then needed a uri to refer to it and then the uri became commonly used to refer to the thing named.

That's a really minimal set of the different ways of looking at it, without getting in to any technical details at all, all three are really common cases of how people use URIs, the in-fighting is just people who've picked one of the three as being gospel, or technically required to make things work.

It's a social problem.

The httpRange-14 resolution picked the first of the above reasons as being the norm, and as requiring the least technical trade-offs. The resolution also accounted for the second case, with precedence given to the importance of having distinct names, rather than network performance or ease of implementation, again simply a design trade-off, one which prioritizes humans over machines.

I definitely cannot explain it any simpler than that.

So, here's a simple-ish summary of the problem - disclaimer, all IMHO of course:

Outline:

    each URI <u> is bound to a thing T by a set of agents SA (this is the naming process)
    <u> refers to T

    some URIs are bound to a set of representations SR over time by the dereferencing process (i.e. GET a URI)
    <u> refers to T, SR

Let's assign the name XT to this class of URIs which are bound to both a T and an SR. (things which name something, and which you can GET content+meta by dereferencing)

Where T == SR this forms a subclass of XT which we'll call YT (just means that the URI is used to refer to the thing you GET, like a web page or an image)

The opposing views:

1. for all <u> in XT, T == SR
   (all members XT are members of YT, doesn't account for T != SR - this is an information resource theory)

2. SR is bound to T not <u>
   (means T == SR && T != SR - this is the content+meta gives information about the thing theory, slash uris name anything)

3. <u> is bound to T, and T != SR
   (SR is unbound to any name, or bound to "some other name" - this is the <u> :retrieved_from "u" approach, or content-location = graph uri)

4. <u> is bound to SR, and T != SR
   (T is unbound to any name, or bound to "some other name" - can't see what it equates to but it's a theory)

5. <u> is bound to T, SR and T != SR
   (can't use deref URIs as names - URI collision, or the chimera theory, this is where information about <u> consists of info about both the information and the real world thing named. Practically it's the same as view 2)

Summary:

View 1, is the httpRange-14 solution (accounting for view 3 with the 303 solution too). View 2 is implied by the REST dissertation (actually so is 1 and 3..). View 3 is the "we don't normally talk about the document" view. All of them have issues for somebody.

Likewise, Moby Dick is not a function, however X being a function from requests to responses, and the functions instantiation as a locus of computation could well be correct.

U can still identify Moby Dick, and all you do is request that X gives you a representation of Moby Dick bearing Y characteristics (content type etc), where U can be resolved to an address for X.

Bearing in mind of course that U can be dereferenced in any number of ways, and doesn't always "point to"/"address" X (stick U in a sparql query, or wayback machine for instance).

The common theme though, which I have to agree with, is that we always use a URI to refer to a source of information (static or computed), whether it's modifying it, or getting some version (representation?) of it.

A representation of information, and U refers to that information (format agnostic) and we retrieve that information by using U as name for the purpose of referencing.

So U is always used to refer to information about a thing, and that thing can be anything.

I'm interested to know, if anybody disagrees?

ps: please don't quote any specification when replying, if the specs had the answers we wouldn't have questions.

You've probably heard of the Social Graph before, that obscure abstraction that holds the relationships between humans, it's locked up in the cloud somewhere inside corporations like facebook, google, linkedin and twitter, with tantalizing bits exposed to you - it's the thing which some people understand, and which some people mine to do everything from social networking and promotion through to highly targeted marketing.

What you may not realize though, is that the social graph concept is incredibly simple, that there's not just a social graph, one graph, but an infinite amount of incredibly interesting graphs, that each graph holds a world full of unrealized, valuable and useful information, knowledge even, and that... let's cut to the point here, 99.99999999% of these graphs are locked away, most people don't even know that they exist, let alone that they're sitting on one of these gold mines, the graphs are locked away unrealized in almost every application and website you use, hidden in databases, and if you're a developer, programmer, db admin or website owner, then you definitely have one or more of these graphs under your control.

This is one of those things I can't stress enough, it's the same as having a pot of gold buried in your back garden, you may not be able to see it, but it's there, and all you need to do is grab a tool and dig it out.

Why Graphs are valuable

To understand, let's look at (and explain) the Social Graph. People use a website like Twitter and make connections to other people, they follow people, each "follow" is saved as a very simple link between the two people: "X follows Y". That's it, if you took 20 of these follows and drew them on a piece of paper you'd see a graph, nodes and edges, people linked together, and this is where things get really interesting and where all the golden information comes from. You see, if you know that "X follows Y" then you can say that "Y is a follower of X", you get the link in the other direction for free. And if you take all the people that "follow bob" and see who else they follow, then take the top 5 of that list, you can pretty safely infer that those 5 people are like bob. This is how "you might like to follow" works, those magical suggestions made by computers, linkedin being a great example of this. By exposing even the simplest of relationships, humans and machines can look at those relationships and infer new ones, indeed it's magical, but really it's simple.

This process of inferring new relationships between things by looking at existing relationships between things, is how the world ticks over. Another example is amazon (and any marketing really), if you buy x,y and z books, then amazon can look at other people who bought those books, see the most common other purchases they've made, and suggest them to you, odds are high you'll want one of them.

However, these kinds of relationships are everywhere, and there's value in every one of them, for example take this blog, each post is tagged with a few terms, which means that each term is linked to another by the post(s) it's tagged to, and each post is linked to me because I'm the author, so if I took all of those tags and seen how they relate to each other and how popular they were, you'd get a pretty strong indication of my technical interests, and if you linked them to me and plotted them over time, you'd essentially see a really interesting view of "me" and my interests, how one thing has lead to another, what things have died out, see the introduction of one topic in my life, branching, strengthening and converging with others over time - personally I'd find that really, really interesting, it's invaluable information in fact which is just locked away in this blog, waiting to be exposed. That's an example of one of these unnamed and unrealized graphs, it's there already, I just haven't dug it up and received the benefits yet.

And this, what I outlined above is just the tip of the iceberg, say i pulled in all the tweets I've messaged and added them in to the equation, say i also pulled in the tweets from my friends, and the tags from the posts I'd read and run them through the same simple process of naming links and looking at the graphs they create. I'd have a wealth of information about almost everything, I'd be able to see where my ideas came from, see that Jeff and Kingsley both mentioned something 6 months ago that I've taken and mixed with my own ideas to create something new. Then I'd be able to analyse information as it came in to, and have my machines filter and suggest not only what I'm interested in, what information I want to consume, but also suggest things I don't know, that because I'm interested in X & Y and talk to Melvin and Manu, that I'll probably want to talk to David and read Z.

If all this sounds ultra complex, it's not, just remember it all comes down to a simple little link between two things, and the graph of those things plotted out, with Y to Z added in to the mix.

The point is, that all of these relationships that are hidden away, the unrealized graphs, are exponentially more valuable and interesting than the boring data we think we have, they contain new knowledge that we didn't know, they allow us to realize things we'd never guess, they contain insight++.

The Three Steps

1. Find the relationships.
2. Name the relationships.
3. Expose your Graph(s).

Finding and Naming Relations: We're at the tail end of the RDBMS generation, so odds are very high that your database is in an RDMBS like mysql, if your database is fully normalised then you'll probably already have link tables, every one of those will contain the relationships you're looking for, odds are you've just given them a generic name like UserPosts or suchlike thinking that the relationships aren't that important (speaking from experience here!), if your database isn't normalized then you'll be looking for IDs from one table mentioned in another, UserID columns and similar, or perhaps foreign keys. Remember there are also natural links between bits of data, any time you have a unique value like an email address, a town name, a postcode, a price, sku, an order number, it can be the hook for a relation, this user and that order have the same email address, these customers and these suppliers are in the same town, might they deliver directly to save on postage and packing + speed up delivery times? When you find, name and expose these relationships you get your Graph(s), and from there you can start inferring things, answering questions, and gaining knowledge you never knew you had; no matter how big or small your datasets are, even if it's in a CSV or a generic format.

Exposing Graphs: Regardless of how you expose these new graphs of relations you've found, just expose them, I'm very pro linked data for multiple reasons, but if you just expose these relations in any way you can, then others (like me) can come along and make relationships between your data and other peoples data, and those relationships are more valuable and interesting than I can ever describe, for example, just think how much easier your life would get if somebody linked up twitter usernames to facebook usernames to email addresses, you'd practically have one single contact list for everybody you knew, and multiple ways to contact them, and that's just a tiny, simple, essentially boring little link between datasets.

Yesterday I had an idea that I wanted to quickly write out and share in some kind of trackable way, where I could go back to it and edit + refine it later on. However, the problem was that a blog post or an etherpad didn't really cut it. So, I thought it's about time somebody made something to handle this, and without much thought quickly registered the domain ideadump.org, sent out a tweet to say just that and ask if anybody wanted to help, then started a quick etherpad to write down the idea, and then sent out another tweet asking for contributions of thoughts.

Here we are, under 24 hours later, and I'm very pleased to say that there's been a fantastic response and things are moving quickly, the site is up and hosted at ideadump.org, there's a github project, a twitter account (@idea_dump), a sketchy start at the UI - but, that's nothing compared to the invaluable feedback already given by the web community, just take a look at the openetherpad document! A huge, well thought out contribution from some great minds, people have spent practically all day contributing in one way of another, notable contributions from @izuzak @bendiken @manusporny @csarven @mhausenblas @jeffsayre @pimmhogeling @melvincarvalho @paulgeraghty - a huge stream of invaluable input that itself shows very promising signs for IdeaDump. Really, thanks to everyone who's contributed so far, it's been a great experience, and we're not even 24 hours in yet!

To make things even better, every part of the project is being created and released under cc-zero and unlicensed, so it's all in the public domain already and will continue on that way.

If you'd like to contribute simply follow any of the links here and start typing in the etherpad or the chat there, message me or anybody else who's contributed, send a tweet to @idea_dump or email hello at ideadump.org or myself - every contribution from a thought to an idea to a line of code is welcomed and encouraged - and if you don't like the domain or the way the projects going, or want to try out a different approach, just fork it, fork the idea, the code, the project, whatever you like, and of course we'll all be happy to help & converge things - let's expose the idea graph and help innovation in our sector along by getting some thought streams to explore.

Personally, I'm thrilled and would like to thank everybody so far, I'm thrilled because as you may have read earlier, I've changed my working model and taken a new approach to development and working in our sector - honestly, it was the best move I ever made, the weight has been lifted from my shoulders, I'm several times happier, everything is working out great from paid work to public domain work to home life to everything - essentially, that one change in the way I do things has made my quality of life exponentially better within just a couple of days, it's only the third day in and everything has sorted itself out, this project and post is just an minor indication of the impact it's had. Whoever you are I urge you to read my previous post and think about how you're doing business, go on, make the jump, it's nice over here.

From this point onwards, I'm an open research and development consultant, working under a new business model for our sector, a one which you will benefit from, regardless of who you are.

I spend all of my time in research and development, converging technologies and investigating new ones, a mix of reading, looking, trying, inventing, hacking, communicating, exploring, testing and refining, the breadth and scope of what I do ranges from overall web architecture down to optimization of a single line of code, and all in between - of course I have my specialist areas and fortes like many others, but generally it's the big picture which I focus on and specialize in.

However, I'm just one part of something much bigger, what makes my new job so interesting is the web community, the projects, the papers, the ideas, the specifications and the passions of others, even the tweets and the mailing list posts, my knowledge comes from you.

So, here's how the business model works..

Some of you need some of the information I know, some of the understanding, others of you are starting ventures and simply don't have the time to invest finding out about all the great projects and techs on the web, let alone how they fit together, some of you are working on those projects and techs out of passion and really need paid for your hard work and effort. Some of you need me to prototype out your ideas by converging technologies and getting a proof of concept going, some of you need the bug reports and patches, or even just the recognition. Some of you need me to talk to your development teams and give them feedback + point them in the right direction, technically or just at an overview level, to make sure your projects become a reality.

So, if I work for with you, and we use open source projects, we'll pay the developers of those projects in some way, we'll talk to them, help them improve their projects, pay for their time, pass on donations and sometimes hire them to tailor what they've done to suit your projects needs or to build the next version they've been planning, the one which has the features you need. And if you don't pay them or donate or give them recognition/thanks, whether that be money or something from their wishlist, something to make their life easier like a new monitor, or some form of promotion, then I will, and I won't work with you again.

Everything I do is open source, not just open but public domain, cc-zero'd or unlicensed, that includes my work on your projects, and yes others will get that work for free, and use it, and fork it, and that's a good thing, because it'll create a marketplace for you, ready made competitors, although of course you'll be ahead of the curve by the time this happens. Of course I won't be giving away your business secrets and game plans, or even how you're tying different things together, you keep your competitive edge and ideas, that's your intellectual property, but anything I work on with you is mine, and I give that to the web community.

I do not deliver finished products, nor do I maintain them, unless the task at hand is to refactor or optimize something. I will however work with your teams to ensure they understand everything inside out, and are happy to run with the project and turn it in to a finished product for you.

If I'm not the right man for the job, or we realize you'd be better with different technologies, then we'll find the right person, or people for you, and transition what we've worked out together over to people who can help you properly, and who specialize in what you need.

Can you hire me to work for you fulltime and exclusively? no to both I'm afraid, I need a stream of interesting projects and ideas coming through me to have any value to you, others and myself - and that's the way it's staying, you can of course retain a chunk of my time on a regular basis if you like though.

The work I'll do will continue whether I'm being paid by others or not, if you think you'll need anything from my generic to do list, or anything related, and you're a part of a corporate entity, then by all means sponsor me, or somebody else, to do them, if you're another person or like me and want to converge ideas thoughts and code, then let's do it. General rule of thumb when working with me from now on is, if you're getting paid to work on the thing we're planning or doing, then so am I, and if you're not, then neither am I.

As for renumeration on paid projects, of course it'll usually be a monetary value as with any consultant or contractor, but sometimes it'll just be a couple of days of talking, or laying out a project plan, turning out a technical spec or such like, when it's a smaller job then why not offer products or services or ask me if there's anything I'm needing or would like for me or my family, if there's a charity or an open source developer I'd like a gift to go to? I'll be doing the same from here on.

So, that's what I do from here on, I'm an open research and development consultant, an open developer, and a contributor to the web communities - I sincerely hope that many, if not most of you reading this join me in this approach, help this open approach to business in our sector along, and look forward to working with you, in whatever capactity that me be.

Thanks for inspiration

I'd like to thank a few people who've led and encouraged me to take this step, Melvin Carvalho who whilst being an open source developer himself, also takes the time to help others, donating everything from time to funds to help fellow developers, he's been a real inspiration to me, likewise Sir Tim Berners-Lee who also leads by example, he not only invented the web but ensured we can use it royalty free, still finding the time to develop open source projects to this very day. I'd also like to thank Richard Blakely and Influxis for both encouraging me to take this step and for being the first to back me in working this way.

Many others have led by example, open sourcing all their work for us all to share, some shining examples are Arto Bendiken, Manu Sporny and the team at Digital Bazaar, the Ushahidi team, the World Wide Web Consortium and those who tirelessly dedicate time to standardize and improve the web - and finally, a thanks to all those who open source, share knowledge and help advance the human race.

All the best for 2011.

Named Graphs

"Named Graph" is possibly the most misleading term used in the semantic web, when somebody says "this is a Named Graph" the temptation is to think "uri-x is the name for this distinct set of triples", however, that couldn't be further from the truth.

The truth, is that "uri-x is a name for some set of triples", it is by no means the only name, and it certainly does not refer to a distinct set of triples. Named Graphs provide exactly the same abstraction as URIs, you give a name (uri) to a resource (graph), and the representation of that graph (the triples) can change at any time, that is, you can only ever reference the "named graph" in it's current state, and never any of it's previous states.

Thus, when you start to describe a named graphs by including it's URI in statements, you are not describing the set of triples at a certain time, nor the representation, rather you are making statements about the abstract concept of the graph, that concept which remains consistent over time.

To illustrate, let's make up a simple named graph, NG, which contains a set of Triples x, and then make a couple of simple statements about NG to say that it was created by #bob, that's it's trusted, and that it contains 23 triples.

Graph <NG> { x }

<NG> a :TrustedGraph ;
:triple_count 23 ;
:author <#bob> .

The trouble is, x is a variable set of triples, at any instance it may refer to literally any set of triples, even an empty set. The statements which meant it was a "TrustedGraph" may be removed or invalidated, the number of triples in the graph can change at any time, and bob may be dead for the last 1000 years with the graph updated by several hundred different authors since. Additionally, the Named Graphs are an abstraction layer on top of, and out with, the RDF data model.

It's safe (and imo wise) to think of named graphs as little more than cardboard boxes, you've no idea what is actually inside them till you look, and anything written on, or about, the boxes, could easily be wrong.

Essentially, much like "cool URIs don't change", to use named graph in any temporally varying environment (like the web or an "rdf store") you need a "named graphs don't change".

Graph Literals

Graph Literals are just that, they literally are the graph, the distinct, non temporally varying, set of triples, in place. A Graph literal is "this distinct set of triples".

To illustrate, let's make up a simple graph { :a :b :c } then make a couple of simple statements about that graph, to say that it was created by #bob, that it's trusted, and that it contains 1 triple.

{ :a :b :c } a :TrustedGraph ;
:triple_count 1 ;
:author <#bob> .

As you can see this is entirely unlike the named graph example from earlier, the statements are as valid tomorrow as they are today, and they're all within the RDF data model.

Further, we can now truly "name" the graph by giving it a URI, we can also attach temporal information to it, in fact because we're still in RDF, we can make any statement we want to add trust / provenance or any other useful information - we are unconstrained. For example:

{ :a :b :c } a :TrustedGraph ;
:triple_count 1 ;
:author <#bob> ;
:uri "http://example.org/whatever" ;
:retrieved "2010-12-29T16:03:12"^^xsd:dateTime ;
:signature [ :assertedBy <#dave> ; :sig "FD345..." ] .

Thus, we can lock the state of any resource at any given time in side a graph literal and then augment it with as much additional information as we want, and we can search through time to see the state of "http://example.org/whatever" on this date or that date, compare, contrast and ultimately do whatever we please.

Further still, graph literals allow us to create Patch and Diff for RDF graphs, to describe rules and inferences in RDF, and much more.

So, unlike named graphs which are like holding a cardboard box and wondering what's inside, graph literals are like holding the contents themselves, you literally are holding the graph.

Named Graphs -vs- Graph Literals

I'm unsure which way the RDF community (and WG) will head with this, but given the above, I can assure that there's no doubt in my mind as to which of the two I think should be incorporated in to the RDF standard.

So here's the problem, who pays? the reality is we're all humans with needs, many of us have full families to support and raise, the work we could and want to be doing is far more valuable to the web at large than simply making another "website" for a paying client, yet the common variety website will pay us well personally, and the valuable open source / public domain work will pay us zero.

Then there's licensing and copyright, essentially I (like many others I'm sure) simply want to open source and cc-zero every single bit of re-usable or reference-able work I do from here forth. In previous years I've managed to strike a bit of a balance where I picked projects based on things I felt were needed generally, or which I wanted to learn, I could release the generic code created and give clients the application specific code, however, increasingly I find that the work I do provides the framework for projects and applications, but not the application itself - just take a quick look at my generic to-do list and you'll see what I mean.

So, what do we do, what do I do? How do I get to this time next year with all these things done, released as a source of reference, as usable libs, and as prototypes, whilst still being a "working man" rather than charity worker for some invisible charity?

This is a big problem our sector needs to address quickly, kickstarter and the like doesn't address it, neither does public domain funding (I'm not a "business" I'm a "me" with no plans to start a fully blown company, tis a waste of all our time if I head down that path). Somebody mentioned a return of the patronage model the other day, maybe linked with micro payments, but until that's common place it feels a bit like scrounging / free loading (even though it's not really).

At the end of the day, I could easily spend the next year doing 100+ hour weeks of v hard work (just like last year), but there's no client. Something has to give, or change here - I along with many others don't want to slow down all of this or even stop all together, but one has to provide for their family.

What do we do, what's the solution here for the many people out there like me?

To do:
Update rdfa-api to align with the RDF API, add full Graph Literal support, add RDFa 1.1 Core parser + profile support, finish generic HTTP based CRUD clients, merge with JS3.

Upgrade to support full N3, work on rule, reasoning and inference methods with OWL and rdfs support + sl/ql/fol based approaches, basic and improving understanding of ontologies, including restriction and owl based data validation.

Spec and upgrade to RDF Object View, spec and implement bi-direction oo-friendly tree views of RDF.

N3 Paths, RDF Selectors (and maybe SPARQL implementation?).

Create hook-in predicate, class and rule based agent framework for data streams and graphs, on top of aforementioned tooling - agents which listen for specific types of data / sets of statements and then do what's needed - to handle simple reflex, model-based reflex, goal-based and utility based intelligent agents.

Combine intelligent agent framework with data wiki support to create intelligent cloud storage agents, personal data streams and helper agents. (agent per uri, each agent has a task, collection of semi-dumb agents in to a data space makes a semi-intelligent agent).

Work on double-agent based auth/ident protocol - four-party, decentralized, temporally valid, webid-like protocol, with built in foothold for trust - details soon.

Leverage HTTP POST for storage / triple accepting agents in a "document which accepts annotations" style. Implement + compare and contrast SPARQL update vs Diff/Path approach.

Web Socket based triple & rdf object streams for personal data streams, filtered data streams, data synchronization and updates.

Generic linked data client side agents for specific tasks - basic social clients (messaging, friend adding, personal data management), and generic apps (like good-relations based client side basket which works on any site), shift of web application state to client side w/ stateless protocols and semi-intelligent agents at both sides.

side topics:
- micropayments via payswarm, open transactions, bitcoin.
- convergence of RDF libs and tooling for interoperability based on standardizing apis.
- p2p web / web architecture & movements on persistent domains, alternative approaches to resolvability/dns, bidirectional/back links.
- More amaya-like browsers/user agents, desktop based http client+cache+server in one efforts.
- RDF serializations (Turtle+Graph Literals ala AMORD in RDF, JSON based serializations / json-ld).

primary long term focus being the convergence of:
- read write acl enabled web of data
- "intelligent" / semantic agents
- internet of things
- augmented reality and innovations/improvements in device + human interface sectors.

A JSON compatible serialization of RDF

JSON is a lightweight text-based open standard designed for human-readable data interchange.

That's not what we need.

We need a lightweight text-based JSON-compatible open standard designed for machine optimized RDF data interchange.

We need it to be JSON compatible because JSON tooling is widely implemented, JSON is well supported, embraced by most web development communities, and of course it's fast and simple.

Stress: It won't be JSON, it'll be JSON-compatible, and to avoid any confusion or indicating that it may be human friendly, we probably would be wise not to put the term "json" in it's name, although we will need to put it in the media type identifier "+json".

We need to standardize because there are numerous competing and differing JSON serializations at the minute, so when somebody asks for a JSON serialization on the web, they get back different results in different places - that's unexpected behaviour, and it's not interoperability - so we need to standardize a JSON-compatible serialization of RDF, with an IANA registered mediatype.

The serialization needs to be machine optimized and usable in multiple different scenarios, else there's no point standardizing it, because other JSON compatible serializations will still be needed and therefore created. Thus we need to define the various use-cases and create a JSON-compatible serialization which caters for them.

An RDF API

There's been a lot of call for cool RDF tooling, specifically in javascript, mentions of a jquery extension and a jquery-like library - I agree that would be nice, but also say why just one? I like and want choice, freedom and to see innovation in the marketplace, I don't just use jquery, I use more libraries and modules than I could name - however..

A library is not an API, and that's not what we need to standardize.

We need to enable interoperability between libraries, and where multiple libraries may or do have overlapping and conflicting functionality, we need to align and standardize it, but only when it produces unexpected behaviour or limits interoperability.

Primarily, this means standardizing interfaces for the RDF Concepts (literals, references, triple and graph) - as soon as we do that, all libraries which implement these interfaces will immediately become interoperable. Web Developers will be able to throw data between libraries, cherry picking the features they want or the coding styles they prefer, library implementers will be able to focus on areas they specialize in, others will be able to stun us with innovative new approaches and tools we'd never have thought of ourselves, and we'll have an open and ever growing truly cool suite of interoperable classes, libraries and tools.

Next up we can standardize interfaces for things like RDF Parsers, because as soon as we do that, all libraries on each specific platform can share parsers, and these can be developed, maintained and improved independent of any specific library - it will also allow the same libraries to be used with specialist low memory parsers optimized for mobile devices, thus broadening their potential user base and giving the end users + developers the best experience possible.

Another set of interfaces which need standardized, are those which are to be implemented by multiple different vendors on the same platform, i.e. the web browsers, i.e. anything near the DOM or HTML, i.e. the RDFa API - which is already being worked on.

Finally, an interface which will make linked data and RDF easier to work with by developers (carrying on from my previous post) is a "Data Object" interface, that is a simple object which holds the description of a single subject, where the properties are keys and the values are native values. I was wrong in my previous post, serving up simple JSON objects will help, but isn't perfect, because we don't know and can't determine whether people will want to use URIs, CURIEs or terms to access properties, thus an interface will be needed to handle this.

This isn't an exhaustive list, and each paragraph above can be considered to handle a different layer in the stack, but standardizing anything substantially more than that will stifle innovation and be counter productive, people need and want different libraries with different coding styles, features and different ways to access and query data. Different tools for different jobs, and for different people doing the same job.

If you disagree, please do share and let me know!

Clarification

Earlier this week I was quoted as follows:

Nathan’s recent post on Opening Linked Data, which is worth reading in its entirety, captures the essence of the issue:

You can’t shoe horn RDF in to JSON, no matter how hard you try - well, you can, but you loose all the benefits of JSON in the first place, because the data is RDF, triples and not objects, rdf nodes and not simple values

In other words, using JSON as the basis for an RDF syntax doesn’t actually win you anything in terms of the ease of processing of that RDF. In fact, I’ll go further and say it has exactly the same bad qualities as RDF/XML.

However I have to point out that I probably didn't make the context clear, I was referring specifically to making a human friendly/optimized JSON serialization of RDF, you can however, very easily, create a machine optimized JSON-compatible serialization of RDF, without the drawbacks of XML (you just don't pin it as being human friendly JSON as outlined above) because unlike XML which requires a full XML stack, and RDF/XML which can be serialized in any one of a billion ways, we have a chance here to make a clean lightweight unambiguous serialization of RDF, one which is based on a lightweight data interchange format and not on a heavy extensible document interchange format.

Hope that clarifies :)

Why? well the sem web community is packed full of the most technically skilled and decent people I've come across so far, so it can't be that, the tooling is pretty damn good, there's loads of data, most of the data's of a high quality, wanted by developers, and certainly more than usable. The concepts, theory and technical aspects are all solid as a rock. In short it's all good, apart from one rather important detail.

Our Linked Open Data isn't really open data, not in the eyes of the common web developer at least. To most web developers on the planet, open data is something they can get access to and use easily.

A good example of 'open data' for most developers, is the Twitter API.

Here's how a developer accesses it in PHP:

  $uri = 'http://api.twitter.com/1/statuses/show/7907258268647424.json';
  $tweet = json_decode(file_get_contents($uri));
  echo $tweet->user->description;

Here's how they access it in Javascript:

  uri = 'http://api.twitter.com/1/statuses/show/7907258268647424.json';
  $.getJSON(uri, function(tweet) {
    write( tweet.user.description );
  });

The reality of the matter is that you can't do this with Linked Open Data, and that's because you can't do it with RDF - and really, honestly, if it's not that simple, the masses won't use it, because, if it's not that simple, they can't use it.

The problems with the RDF formats

They're not perfect, and they are a very mixed bunch, for a change, let's look at the negatives.

RDF/XML
- Requires full XML tooling
- Can't read or write by hand
- butt ugly

Let's be honest, unless you have a full XML and RDF stack and you know what you're doing, RDF/XML is simply a no go zone.

RDFa
- Requires HTML/DOM/XML tooling
- An extension to a markup language, designed to augment annotated documents.

RDFa is great, but not for the general data use case, it's not a simple data interchange format like JSON, and you can't publish or consume it without specialist tooling, in fact it requires an even bigger, more complicated, stack than RDF/XML.

Turtle
- Requires a custom parser
- It's not yet seen as a data format by the masses.
- Doesn't have a registered media type.

If we're all honest, Turtle is the king of RDF serializations, it's small, powerful, easy to write and read, requires minimal tooling to parse. In fact, I'd quite happily say that Turtle is the best all round data format, period.

RDF/JSON and JSON-LD
- Square peg, round hole

You can't shoe horn RDF in to JSON, no matter how hard you try - well, you can, but you loose all the benefits of JSON in the first place, because the data is RDF, triples and not objects, rdf nodes and not simple values - I fear I'd better explain, quickly:

The benefit of JSON is that you can do the following:

  var u = tweet.user;                                // nested, simple objects
  write(u.message);                                  // simply "a string of text"
  if(u.geo_enabled) {                                // a boolean true
    var d = u.statuses_count * u.favourites_count;   // numbers..
  }

Anything more complicated than that and you've lost 95% of the benefits of JSON.

Here's the code to do that if(u.geo_enabled) with JSON/RDF:

  var tweet = rdf['http://example.org/tweet/12343'];
  var user = rdf[tweet['http://example.org/property/userid']];
  var geoenabled = user['http://example.org/property/geo_enabled'];
  if( Boolean(geoenabled.value) ) {

and JSON-LD:

  var tweet, user;
  for(o in jsonld) {
    if(jsonld[o]["@"] == 'http://example.org/tweet/12343') tweet = jsonld[o];
  }
  for(o in jsonld) {
    if(jsonld[o]["@"] == tweet['twit:userid']) user = jsonld[o];
  }
  if(user['twit:geo_enabled']) {

Remember, those two examples are only for the simple if line from the benefits of JSON example, can you even imagine all four lines?

Clearly, RDF in JSON is of little to no use to anybody, you can see plainly yourself, 95% of the benefits are lost and it's just another RDF serialization that's pretty much unusable without tooling. The only benefit JSON serializations of RDF have, are that you don't require an XML stack, which is quite a large benefit tbh.

The problem with RDF

I've been a little unfair there, you see the problem isn't with the serializations, we can't make a "better" serialization of RDF for general web developers, because the real problem is that the data's RDF, it's triples not simple objects, URIs rather than simple terms, RDF Nodes with a language or type, and not just simple values.

An array of RDF triples, or a structure of RDF, just simply isn't usable in most (all?) programming languages, by a typical web developer, without specialist tooling and libraries or APIs.

Am I saying RDF is bad? no of course not, it's awesomely brilliant in every way, it powers a paradigm shift and will have huge positive effects on the web and the human race. You know the score :)

What I am saying, is that we're not backwards compatible, we're not making our data open in formats which are usable by normal developers, developers who need and want the data, want the links, but not the semwebbery. Hell even most of us who are heavy sem web users only consider the ontology+reasoning side enabled by properties-with-uris some of the time, most of the time <http://xmlns.com/foaf/0.1/name> might as well just be "name".

Opening Linked Data

So, here's what we need to do, we need to just accept that although we publish linked data as RDF, we also need to publish the data as simple objects so the world can use the data.

Given the linked data:

  @prefix : <http://webr3.org/nathan#> .
  @prefix foaf: <http://xmlns.com/foaf/0.1/> .
  @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

  :me a foaf:Person;
    foaf:age 29;
    foaf:holdsAccount [ foaf:accountName "webr3";
        foaf:homepage <http://twitter.com/webr3>;
        rdfs:label "Nathan's twitter account"@en ];
    foaf:homepage <http://webr3.org>;
    foaf:knows <http://example.com/bob#me>;
    foaf:name "Nathan";
    foaf:nick "webr3", "nath" .

  <http://example.com/bob#me> a foaf:Person;
    foaf:name "Bob" .

We also need to publish it like this:

{
  "http://webr3.org/nathan#me": {
    "a": "http://xmlns.com/foaf/0.1/Person",
    "age": 29,
    "holdsAccount": {
      "accountName": "webr3",
      "homepage": "http://twitter.com/webr3",
      "label": "Nathan's twitter account"
    },
    "homepage": "http://webr3.org",
    "knows": "http://example.com/bob#me",
    "name": "Nathan",
    "nick": [ "webr3", "nath" ]
  },
  "http://example.com/bob#me": {
    "a": "http://xmlns.com/foaf/0.1/Person",
    "name": "Bob"
  }
}

and now one can do: me.holdsAccount.label and get back a string, in any language.

What have we lost?
Well nothing in the grand scheme of things because we're still publishing the RDF in other formats via conneg, however in this specific serialization of the data: we've lost the properties, the .language and the .type, although basic types are still there, dates are detectable, numbers are supported, booleans are supported, everything else is just a PlainLiteral, a string.

What's still there?
The data, http names for things, follow your nose, rdf types ++usable-accessible-data in a web standard format. It's 3.5 if not 4.5 star data!

Other considerations
Probably be wise to allow direct access to a .json URI too, so people can simple-GET the data (in addition to exposing via conneg).

Should be an easy hit, any good reasons why not?

The other RDF Serializations

While we're here, there are a few other things that need tidied up, properly.

Turtle
Let's make it the standard RDF serialization, with a proper registered media types of application/turtle and text/turtle, fix any bugs in the spec (if any), and possibly allow an optional comma in those lists (1,2,3).

Let's just accept that RDFa is great, but sometimes you just want to embed a chunk of RDF in an HTML document, you know we all want to on occasion, people are shouting for it, it's easy to do, to deploy, doesn't break anything, and it's a really easy hit - so, in the Turtle standard spec pop a note that shows how to include it in an HTML document.

<script type="text/turtle">
  // turtle in here, as-is, no special encoding
</script>

RDF/XML
Leave it as is, let it run it's course naturally, and in many respects just forget it moving forwards, everybody supports it already, that won't change, but there's approximately zero need to keep pushing it.

RDFa
As awesome as it is, just see it for what it is, RDF in attributes, it's like the missing markup features of HTML, for annotating documents and describing the things described in the documents with annotations. It's not a simple data or RDF format, and it's not really suited to just dropping chunks of machine readable RDF in to an HTML document, Turtle in HTML will do that far better.

RDF/JSON and JSON-LD
Standardize a JSON serialization as a replacement / alternative to XML - but, admit and stipulate before hand that it's not usable as-is, or really writable and is arguably human readable. It simply needs to be a fast, unambiguous, optimized for the machine, RDF serialization - no bells and whistles for humans, no "12^^xsd:type" in a string - just something that you can JSON.parse and run circa 10-20 standardized lines of code over to get back an RDFGraph of RDFTriples.

Fin & end.

1. Create a vocab or profile syntax that lets you give short (non namespaced) names to ontology classes and properties.
name = foaf:name
label = rdfs:label
where = is like owl:equivalent*, don't care about the syntax of this file at all, even RDF using owl:equivalent is just fine.

2. Create a way to reference this from an rdf file, something similar to profiles.

@proxy http://ex.org/my-proxy-ontology .
@prefix : .

:me a Person; name "Nathan"; nick "webr3"; birthday "31-03" .

and just to detract from this, I'd actually really quite like this syntax:

@proxy http://ex.org/my-proxy-ontology .

:me a Person; name Nathan; nick webr3; birthday 31-03;
knows (name Michael Hausenblas), (name Melvin Carvalho) .

literals shouldn't need enclosed in quotes unless they contain syntax grammer (although \ delimiting could cover this), it'd also be nice to be able to talk about the uri you just mentioned in context, and also to leave out obvious stuff like "a foaf:Person" on who you know, cos of course they are a person. Further, literal types could easily just be inferred by the predicate, and further still the ontology of the predicate should/could contain all the rules to validate the value using owl data type restrictions. (note, doesn't this cross over with xsd restrictions?).

just a random snippet of thoughts / brain dump!