This is quite a dry subject, and I could be wrong (in fact in some ways I want to be proved wrong, this is how we learn), but do read on if you're interested.

Example

Over the past few months I've hit on a number of occasions where I was convinced I needed Named Graphs in order to address the task at hand.

A notable example is the scenario where using WebAccessControl and the ACL ontology, a system would have to figure out just who should be given access to a resource, and who should be denied.

In this example I'll cover the notion of ACL for "groups" in a linked data world.

The task at hand is to allow access if:
the graph serialized within the document obtained by dereferencing the URI of the group states the <webid#me> is a member.

Otherwise written as:
if we dereference <groups#admin> does the graph returned include the following { <groups#admin> sioc:has_member <webid#me> }

Or in SPARQL:

ASK
GRAPH <groups> {
  <groups#admin> sioc:has_member <webid#me>
}

In this example we *do not* want to dereference the users webid to see if the graph returned specifies that { <webid#me> sioc:member_of <groups#admin> } , or indeed consider the open world possibilities that another yet unknown graph could assert that the user is a member of our admin group, as that would breach security.

The ACL

To proceed with the example, consider the following ACL:

[] a acl:Authorization ;
	acl:accessTo <https://example.org/sensitive> ;
 	acl:agentClass :mygroup ;
 	acl:mode acl:Read .

:mygroup owl:equivalentClass [
 	a owl:Restriction ;
 	owl:hasValue <groups#admin> ;
 	owl:onProperty [ owl:inverseOf sioc:has_member ];
 	] .

The Problem

The problem proposed by this ACL is that any of the following four sets of triples would infer that <webid#me> would qualify as an instance of :mygroup (or a member of <groups#admin> if you prefer).

• <webid#me> sioc:member_of <groups#admin> .

• <webid#me> _:x <groups#admin> .
  _:x owl:inverseOf sioc:has_member .

• <groups#admin> sioc:has_member <webid#me> .

• <groups#admin> _:y <webid#me> .
  _:y owl:inverseOf sioc:member_of .

In other words, the ACL does not specify a "Named Graph" to query, and at the moment, no way exists to specify with (OWL or RDF) which "Named Graph" to query / trust.

This, point in case, is one example where I saw the need for Named Graphs in RDF and OWL.

Another way of looking at it

You will have noticed the notion of "Named Graphs" creeping in above, seems like a logical thing to say, especially when you consider that to process this ACL and grant access you'd probably use SPARQL, and specify a Named Graph to query over. However, much of what follows arose because I'd decided not to use SPARQL, and rather to code an ACL processor in my preferred language.

If you consider the situation, the ACL processor which decides if access should be granted or not, must implicitly "trust" the document which contains the serialized ACL graph. That is to say, that it must by extension trust any resources pointed to by said ACL, and if it doesn't then the ACL isn't fit for the purpose.

It's also important to note that "trust" is context specific, in this case we trust the resources pointed to by the ACL for the purpose of WebAccessControl.

One could then pretty quickly conclude that in this scenario the ACL processor already know's how to process the ACL, it must only use resources it trusts, therefore it must only allow access if the graph serialized within the document obtained by dereferencing the URI of the group states the <webid#me> is a member.

(because <groups#admin> is specified in the ACL, and thus by extension, trusted)

Named Graphs in SPARQL

The aforementioned logic would also apply if I was using SPARQL to process the ACL, it would equate to the ACL processor asking:

ASK
GRAPH <groups> {
  <groups#admin> sioc:has_member <webid#me>
}

But again this is very context specific to the example, let's consider for a moment that the URI for the group could have been a non-fragment URI, <groups/admin> for example.

This leads us to an important problem, when we dereference <groups/admin> it would have to 303 See Other through to a different URI, let's say <data/groups/admin> - which would then mean that the Named Graph to be used was <data/groups/admin> - this URI, you may note, we do not know when we are writing our ACL; so if we ASKed the above SPARQL, the results would always come back negative, since their is no GRAPH <groups>.

The URI of the Named Graph issue is compounded by modern web servers and publishing practises, because <data/groups/admin> could easily be content negotiated (or rewritten), thus giving various final URI's of <data/groups/admin> or <data/groups/admin.rdf> or <data/groups/admin.ttl> or <data/groups/admin.n3> and so forth. One could quite easily (and often does) end up with the same Graph repeated multiple times within a quad store, all under "different" "Named Graphs".

I'll expand on a possible way of addressing this problem further on.

Directionality

Previously I mentioned that the ACL processor didn't have a problem with the above ACL, because it by nature trusted all resources which were mentioned in the ACL graph. However, again this is very context specific.

Let's consider for a moment an inverted ACL, where we want to allow access if:
the graph serialized within the document obtained by dereferencing the URI of the users webid states that <webid#me> is a sioc:member_of <groups#admin>.

We don't know the users webid ahead of time when we write the ACL, so again we have no way of writing how to trust a resource - it is critical to note that even if RDF(2) did support the concept of Named Graphs, it still wouldn't address the situation because we wouldn't know the Named Graph ahead of time, in order to trust it!

If we now consider the following ACL:

[] a acl:Authorization ;
	acl:accessTo <https://example.org/sensitive> ;
 	acl:agentClass :mygroup ;
 	acl:mode acl:Read .

:mygroup owl:equivalentClass [
 	a owl:Restriction ;
 	owl:hasValue <groups#admin> ;
 	owl:onProperty sioc:member_of;
 	] .

The outcome of our previous logic concludes that again we should be querying the "trusted" resource <groups#admin>, which gives us another problem, that's not the resource we want to be asking in this scenario.

The only thing that remains, and I'll later argue the only thing that ever matters in a web of linked data, is direction.

If we analyse the first ACL closer, we can see that we ultimately used the direction inferred by the presence of owl:inverseOf to place <groups#admin> in the subject position, rather than the value/object position it could have been in, indicated by the presence of owl:hasValue. (bare with me).

In this example, we can use the strong semantics of owl:hasValue (and lack of owl:inverseOf) to place <groups#admin> in the value/object position, and thus our ACL processor can come to the outcome we want, which is to look for the a triple with the meaning { <webid#access> sioc:member_of <groups#admin> }, and that means dereferencing the URI in the subject position, in other words asking the graph serialized in the document returned by GETting <webid> if it contains such a triple.

I've applied some understanding to OWL that quite simply isn't there though, as I earlier stated both ACL examples could easily equate to looking for any one of those four sets of triples.

However, this is the point - machine understanding of data is in the domain of the machine, the application doing the processing. And "truth" or "trust" is entirely context specific.

I'm increasingly convinced that the combined context of the data in a graph and the context under which that graph is being queried, specifies or infers in which direction you want to be reading, and directionality can be determined with linked data by dereferencing whichever uri you place on the left / in the subject position.

I recently found that Tim Berners-Lee wrote about this in a blog post entitled Backward and Forward links in RDF just as important:

One meme of RDF ethos is that the direction one choses for a given property is arbitrary: it doesn't matter whether one defines "parent" or "child"; "employee" or "employer". This philosophy (from the Enquire design of 1980) is that one should not favor one way over another. One day, you may be interested in following the link one way, another day, or somene else, the other way.

Key here is the sentence "One day, you may be interested in following the link one way, another day, or somene else, the other way.", and that is exactly what all these examples are doing, following a link one way, or the other way.

To conclude this part, in every scenario thus far where I've thought I needed Named Graphs, it turns out that I in-fact needed directionality - and because I'm dealing with Linked Data, whatever I place in the subject position defines the URI which I need to dereference, and ultimately the Graph(s) which are considered when resolving the answer to the question being ASKed.

I'd thus suggest that "Named Graphs", do not exist in a web of data, they are needed in N3 and when using rules, because all data is often in a single file, however that is not the case for Linked Data, where we dereference.

Back to SPARQL and Named Graphs

Previously I mentioned the complications with the way we currently use named graphs in SPARQL and in our quad stores, where the URI we end up using could literally be, anything; and often we get duplicate data under different graphs.

To address this, I'd suggest that what we should be storing as the graph ?g value, is not some made up "named graph" but rather: the dereferenced URI which we initially requested.

• in the case of <group#admins> this would be <group>.
• in the case of <group/admins> this would be <group/admins>

To clarify, *never* the URI that a GET request finally resolves to, and *always* the initial dereferenced URI we requested.

The above ensure that we'd never have duplicate data in our quad stores again, that SPARQL queries including a FROM clause always dereferenced, that publishers and web server administrators were free to relocate and restructure their data, and ultimately make for a much nicer, healthier web of data.

Cool URIs don't change, and they wouldn't, just because the final document serializing a graph may move to a different URI, doesn't mean the original URI has to change.

Conclusion

Apologies for the length of the post, but I figured everything needed covered, in context. Simply put we need to focus less on Named Graphs (which IMHO aren't needed) and focus more on directionality. Every problem I've encountered thus far is covered by what Tim said years ago: "One day, you may be interested in following the link one way, another day, or somene else, the other way."

Comments?

I'm primarily documenting this journey for my own benefit, for reference and to unload it from my brain; but hopefully it'll be of use to the wider community and any feedback will be massively appreciated.

Here goes, I'll start by analysing the web thus far:

The Web till now

The power and the success of the web so far, in my opinion, has come from four main things:

• The URI
• Hyperlink
• The Resource
• HTTP and it's RESTful design.

More importantly it's the combination of the four working together that makes the web so great, because, they let you cut out everything else and go straight to the resource you want. This is a point that we need to concentrate on for a minute.

Going straight to the resource

Back at the start of the web, this allowed people to (for the first time) jump from a resource in the bowels of one companies hierarchy straight to another resource in a different companies hierarchy - very much like reading a book, looking at the references and suddenly having the book or paper it references right there in your lap - amazing to say the least.

Skip forwards a few years and we have the search engines, suddenly simply by typing a few keywords you can jump right to a resource (page/image/...) anywhere on the web. Fast forward some more and we get to web 2.0 where again people are amazed every time direct access to a resource is exposed. Yup.. all your web 2.0 is just this simple principal..

An RSS feed, well it lets you read a resource (a post) outside the context of the website and inside lets say google reader. You can rip a resource (video) out of youtube and embed it anywhere you like. You can interact with a web application super fast thanks to targeting a resource directly with say ajax and only updating that resource rather than updating the entire view (page). You can interact with web applications using desktop clients because they let you access one resource at a time; and so on and so forth, virtually every improvement you see on the web comes down to that one thing, directly accessing a resource (and creating resources at a more granular level).

How we made the web faster

Negating the rather obvious upgrades in technology over the years, there is one primary thing that speeds up the web and virtually everything computer oriented, the cache.

Before all the web 2.0 stuff, resource caching was at an all time high and was making the web faster for all of us; caching at the resource level is enabled by HTTP and its RESTful design. Control Data allows us to limit how much information needs transferred over the web, request an image once and it gets transferred, request it a second time and thanks to caching and HTTP odds are very high that it won't get transferred again. When you consider that the average web page can easily have 30, 50, 300 images and static files embedded in it this is a huge speed increase, and frankly one we could not live without.

Skipping forwards to web 2.0 and the present day again, we've gone wild with caching; anybody who's been involved with a high traffic site will tell you that the only way to do it is to cache everything you can; from data in memory, through to code and op code caches. But this is only half the story.. a strange this has happened..

How we made the web slower

Simply, we forgot HTTP and a RESTful web somehow - that all important web caching whether it be at intermediate servers or in a web browser, it's forgotten.

To illustrate, if you view an image and then view it again, it'll be there instantly - why? because last-modified, etag and other control data is sent by great web servers like apache for static files, until you force a refresh or the file changes on the server you'll simply get a 304 response telling whatever cache down the line to use it's own copy instead. Now, try jumping on to a web page, even this one and you'll find the whole thing is reloaded, every time. I'd estimate that circa 80% of all pages you visit are fully reloaded every single time you see them, if not more.

Here's the reason - most pages are generated by scripts now, and something that goes unnoticed by most developers is that the web server (like apache) hand over *full* control to the language runtimes, and in turn to the developer. In other words, unless developers are calculating, receiving and sending control data for each response, and validating every http message in to their scripts, then most of the benefits of HTTP and RESTful design are completely lost; especially caching.

Here's a fact, whether you agree with it or not, to me it is a fact: the web has to be RESTful for it to work properly, whether it's a web of documents, or a web of data, or both.

Looking at the current state of Linked Data

Linked Data is amazing because it takes the big four I mentioned earlier (URI, Hyperlink, Resource, HTTP) to a new level; we create resources at the most granular level possible, assign them URIs, link them together with typed hyperlinks then expose them via HTTP.

Notice I didn't mention REST in there? that's because I (and I'm not the only one) don't feel that Linked Data is currently RESTful. And as we can learn from web 2.0, unless this is addressed we'll face major problems down the line. In addition, because of this lack of RESTful-ness I feel like the data isn't linked; simply using URIs from different datasets on both sides of a triple does not link those datasets, well not from a client perspective anyway.

To expand and refining the issues:

SPARQL Silos

Issue one, is that SPARQL and the servers with RDF stores which power it are positioned at the wrong side of the client / server relationship imho. Because each major dataset effectively has it's own server and access point (SPARQL interface) it means that when you query it, it can only return the Linked Data which it stores. This leaves us three options at the minute:

• let that server pull in remote Linked Data and store it too (which makes the server fill up and slow down, and turns it in to a silo).
• use one great big server that tries to store all the linked data (which feels like a silo all over again to me, not distributed at all).
• Run our own server and only store limited data in it (limited.. and again a silo I guess)

If we moved SPARQL to the client side however, then all it would need is a starting point from which it could traverse the web of data, only pulling in what it needed for a query. This may sound slow but if all data was exposed as resources like it should be, and with control data so it could be cached, this slow down would soon disappear; lesson from web 1 and 2!

With regards the caching, this could happen at traditional intermediate caches within the internet and at ISPs, locally in client side triples stores (like a browsers cache) or the existing big servers that attempt to store all the linked data could be repositioned as linked data caches.

For example a small RDF document could simply delegate seeAlso http://datacac.he/http://subject.uri and that linked data cache could return back all the information it knows about the subject by returning the RDF results of a SPARQL describe. This alone would be a HUGE speed up, prevent silos and create a real web of data.

In addition, this would keep all linked data transferred through the web in RDF format, and thus machine readable and typed. At the minute we have lots and lots of SPARQL queries, which essentially are just untyped junk data that a machine couldn't possibly understand - SPARQL results remove all the goodness from RDF and give us something that is domain and developer specific, not re-usable. Think about that for a moment..

Clarification: I'm not saying SPARQL + RDF stores shouldn't be on the server side, they should as they are needed in most cases, I'm simply saying that the primary interface to linked data shouldn't be SPARQL over HTTP to a remote SPARQL endpoint. Rather we should be accessing RDF documents, or entities if you like via HTTP.

RESTful RDF

Issue two, the focus has been on getting data on the web, finding ways to link it, access it, store and query these vast datasets; and the work done thus far is amazing! But now that's handled it's time to go back to basics and find ways of both getting and publishing Linked Data RESTfully, at a granular per resource level.

This means handling RDF like ATOM, and essentially making atompub all over for RDF (as many are thinking and working on). I feel that regardless of what's implemented behind the interface, and whether triples stores and SPARUL are used, we still need to manage RDF / Linked Data in terms of documents and entities for it to be RESTful.

An additional issue raised by this is loosing the notion of a quad, g s p o, Named Graphs are vastly important to linked data, but we need to get named graphs in to triples and out of quads so we are always working with RDF through HTTP.

Also worth noting that temporal, provenance, multi-language, multiple representations etc will all need handled too; without using any HTTP extensions; no point half baking it or making the solution dependant on drafts - needs to work with the Universal Interface!

First Step

The above means one of the first challenges and things I'll try to tackle, is to find a way to fit a RESTful RDF publishing and exposing protocol in to the shared http space on a web server; taking in to account things like content negotiation, multiple representations, versions / time varying representations, and backwards compatibility with the current web.

note: I'm not going to define the protocols, plenty of more intelligent people than me are working on these things, just leverage a space where a full RESTful protocol can work in unison with the way we currently do things so that it's transparent to browsers and visible to linked data clients. This should then allow a stable test environment to try out different ways of doing things and test that the current web doesn't break.

To be continued.. often and frequently. I'm blocked on my current, v important project, and need to address these things.