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..

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.

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.

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 :)

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!

What do you like about RDF?
The triple, (dereferencable) URIs as identifiers, use of ontologies/schemas, ^^typed literals, various different serializations.

What do you dislike about RDF?
documentation is pretty much serialization specific (RDF/XML) should be serialization independent
reification, bags and sequences in the rdf/xml specification
subject and object definitions do not match (lack of literal subjects, lack of collections in the subject position, lack of graph literals)

Most Important Addition to RDF
subject and object both taking the same values (literal subjects), graph literals, collections in the subject position, and variables allowed even if not supported by specific or existing serializations.

Tidy up RDFS and add in much needed values which currently reside in owl and a few other ontologies - RDF should come with a base vocab that covers most rdf specific needs.

Priorities
* Make RDF smaller/simpler: [ No opinion ]
* Make RDF larger/more powerful: [ No opinion ]
* Redesign some parts of the RDF/XML syntax : [ No opinion ]
* Redesign some parts of the RDF model: [ 5 +++++ (highest) ]
* Improve RDF's suitability for data/database work: [ 1 + (lowest) ]
* Improve RDF's suitability for semantic/KR work: [ 1 + (lowest) ]
* Provide better syntaxes for RDF: [ 5 +++++ (highest) ]
* Provide better documentation: [ 5 +++++ (highest) ]
* Explain the business case better: [ No opinion ]
* Provide better communication, community support: [ No opinion ]
* Help people find or develop RDF vocabularies: [ 4 ++++ ]
* Develop more compelling applications: [ No opinion ]
* Develop standard vocabularies: [ 5 +++++ (highest) ]
* Work on RDF Security: [ No opinion ]
* Work on RDF Trust & Provenance: [ 3 +++ ]
* Work on Synchronization, Distribution, and Versioning of RDF Data: [ 3+++ ]
* Work on bridging between RDF and XML: [ 1 + (lowest) ]
* Standardize RDF API in Javascript: [ 5 +++++ (highest) ]
* Standardize RDF APIs in other languages: [ No opinion ]

re: Improve RDF's suitability for X, if you improve the model this should happen automatically.

re: Make RDF smaller/simpler/larger/more powerful, again this is conflating issues, RDF should be looser so that serializations can tighten up by supporting certain features.

re: trust, provenance, synchronisation, distribution, versioning - imho this is all out of scope, work could begin on this if the model was loosened up to be more n3-like (graph literals); get the model right and these headaches become much easier to handle.

re: backwards compatibility, this should be a non issue as any looser definition of RDF can be countered by defining existing serializations as including a subset of RDF's features - to limit the next decade based on the mistakes or lessons learned from the last decade is, imho, unethical.

Add Core Support for Working With Multiple Graphs
graph literals, anything else is a work-around imho. if graph literals +5 in every respect, else, meh.

Create a Standard JSON RDF Syntax
critical imho, unsure if it should come under this working group though.. but if it's the only place and time then here it must be, as RDF/JSON is the most important serialization for the next decade of the web, easily.

Make Turtle a W3C Standard
great yes, but only after getting the core model sorted out, tweaking turtle to handle the changes (should be v easy given n3 heritage) then standardize under separate cover if possible - else, if not possible under separate cover, then imho must happen - the "why not" train of thinking comes to mind. Turtle *should* already be a standard.

Indicate Which RDF Features Are No Longer Best Practice
either deprecate them or leave them be, "weak deprecation" is nothing more than politics; keeping them for BC and allowing a new generation to use them a poor choice imho, deprecate them, mark them as deprecated, then if implementation want to be backwards compatible they still can (and probably are).

Extend RDF/XML
would much rather see RDF defined without any changes to serializations, let serializations conform and revise under separate cover.

Revise Semantics for Blank Nodes
this issue is imo nothing to do with RDF (indicates a problem in sparql).

Create Standards for Deployment of Linked Data
great idea but nothing to do with RDF core imho and would add way to much scope. can't rate it as a +5 because I view it as orthogonal.

Define Some Useful Similarity/Equivalence Properties
100% behind this one, as per J Hendler's RDFS3 proposal - nigh on critical to the wider community moving forwards.

Define a Namespace Packaging Mechanism
personally view it as a bell and whistle proposal, v low priority imho - however loosening the rdf spec to all namespaces to be either included or pointed to in order to allow future work like this would be a good idea.

Change RDF Semantics to Plain Data (SPARQL) Style
I'd just remove this from consideration if possible.

Explain How to Determine What a URI Means
? give something a uri, describe it with RDF, consult that RDF to read it's description, meaning is different in every context and.. unsure why this is on the list tbh.

Allow Literals as Subjects
+5, must happen imho.

Improve Integration with Syndication Systems (Atom)
it should be easy enough, indeed it's already possible - but syndication should and could be done with RDF, lack of graph literals pretty much makes RDF a no-go area in the message space, which is sad..

Other Comments?
IMHO, TimBL (http://www.w3.org/DesignIssues/RDF-Future.html) and Jim Hendler (http://www.w3.org/2009/12/rdf-ws/papers/ws31) have everything covered in their proposals, I completely fail to understand why these two proposals aren't just done as they cover everything and are imho golden.

If I could click my fingers and decide what happened, I'd get everybody working on making the changes outlined by TimBL and Jim Hendler, then get a group on to doing RDF/JSON under supervision of Sandro Hawke, Manu Sporny and possibly Jeni T. Get Turtle aligned with the changes (should be an easy hit) then clean up RDF/XML and define it as supporting a subset of RDF. Quite sure this won't happen though and I'll be completely confused as to why not.

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?

OpenCalais and Zemanta usage details and service comparison.

The demo leverages OpenCalais in order to pick up references to things, which are returned in most cases as string literals; OpenCalais can also be configured to return back socialtags which give a broad stroke idea of what the document is about, again with string literal "tags". With regards the references (semantic metadata, Entities, Facts, Events etc.) which OpenCalais returns, whilst it is generally string literals, it also returns back vital Type and Relevance information, so in the case of "London" it will also assert that London is a City. Even in the case where it doesn't previously know what a thing is, it can work out that say "Frank Neverbeenheardofbefore" is a Person.

Zemanta is also leveraged, the primary difference between Zemanta and OpenCalais (and thus the need for both services) is that Zemanta focuses more on accurate tagging of text. Primarily though, Zemanta tags (again string literals) are meaningful tags which are commonly known and are referenced to either existing Linked Data identifiers such as http://dbpedia.org/resource/London and further information about the tag (or thing), in the case of the aforementioned London, then it will often also provide links to the wikipedia page for London, the official homepage to the city of London and a link to show the position of London on google maps.

I should point out that ever increasingly OpenCalais also returns back Linked Data too, for instance in the case of London they have given it an HTTP URI which can be dereferenced to retrieve more information about London. At a very crude estimation I would suggest that (depending on the subject matter) OpenCalais returns Linked Data URIs for about 15% of all references it finds to well known "things".

Weighing up the two services I couldn't say that one is better than the other, both have advantages and disadvantages, the only way to get a decent overall picture is to use both. for the benefits of feedback to both of these great services though, here is a general comparison:

note: none of these figures are from exact tests, they are from extensive developer usage of both services as I've used them both since they were made public.

Zemanta is generally 2x as fast for average texts (the size of this post for instance) and as much as 5x as fast for longer texts. Average for Zemanta being 0.7 to 2 seconds. Average for OpenCalais being 1.5 to 10 seconds. It may also be worth noting that the availability of Zemanta is somewhat higher than that of OpenCalais, perhaps 1 in 250 calls to OpenCalais will fail.

OpenCalais does a lot more heavy work than Zemanta though, and *really* semantically analyzes the text to figure out a wealth of information. In this respect the tables are completely turned and Zemanta consitently deals with providing a few high quality known tags; where as OpenCalais often provides at least 10x as much information about a given text, including relevance and type as mentioned before. OpenCalais also extracts Facts / Events, and further it can figure out that "Jim" is also "Jim Bob", and that Jim said X about Y on date D.

Generally you can trust the data from Zemanta 99% as it deals with "known" things, however due to this in some cases very new topics (such as IPad for the first few days after its announcement) remain unknown. Due to the nature of OpenCalais and it's dealing with the unknown you need to take more time to verify what it has returned, however when OpenCalais assigns a LinkedData identifier to something or provides more information you can 99.99% trust that it is entirely accurate.

It's worth noting that both of these services do different things though, and both do it extremely well, Zemanta "tags" and OpenCalais "semantically extracts information", in some respects I was hesitant about comparing the two, as in the context of what I'm doing both are needed and both are equal, however in different contexts both do different jobs and there is a need for people to select one over the other.

Out of all the competition though, I would highly recommend both Zemanta and OpenCalais over their respective competitors, and do hope that neither of these great services ever decide to target each others markets. (e.g. they compliment each other well and both do so well because they stick to what they are good at).

extractor.data.fm details

This demo deals primarily with figuring out what a document is about; in that it aims to provide back a list of:

• Categories
  A list of 1-5 dbpedia (and therefore wikipedia) categories which the provided document would be categorized under if it were a wikipedia article and had been categorized by a huma who was knowledgeable in the subject domain(s) of the text.
• General Topics
  A short list of the general and broad-strokes Subjects covered by the document, these can are distinct from the primary specific subjects covered and the categories, and in many ways can be seen as the most common intersections between the primary specific subjects discussed.
• Primary Subjects
  These are the specific subjects covered in the document, not just the things mentioned, but the things actively discussed within the document, the primary subject matter as it were.
• Related or Mentioned Subjects
  Whilst I've termed them "related" as in dcterms:related, these are simply things which have been detected in the document or text and which are not primary subjects; in many ways "mentions" may be a more appropriate term.

Out of the above list, the two services do the heavy lifting to give the demo it's Primary Subjects and Related Subjects; in short OpenCalais' SocialTags and Zemanta's Tags give us back our Primary Subjects. Whilst OpenCalais by way of the semantic extraction provide us with the Related Subjects, namely all those extracted semantics which have the Type of a real thing (not an IndustryTerm or Event) and which are not all ready a Primary Subject; additionally those extracted semantics which are not tags but have a relevance higher than a certain score are boosted up to be Primary Subjects too.

A primary and initial function of the demo is to associate the tags returned by both services together, and figure out when each is talking about the same thing; this is covered first by dealing with the linked data they return; where both services are talking about the same thing you simply know this unambiguously due to the nature of http URIs and them both being the "sameAs" each other. After this two chunks of unhandled data remain, Zemanta tags which have not determined to be the sameas OpenCalais ones; and OpenCalais semantics which we have a string literal name for and a type.

In step Openlink Virtuoso 6.1 (open source edition!) with most of dbpedia 3.4 loaded in to do the heavy lifting from here on; Virtuoso is a really powerful bit of kit and has replaced mysql/sql server/postgres, rdf store and web dav server in my typical server stack. The public lod and dbpedia endpoints really do no justice as to just how powerful and fast Virtuoso is, queries which take a few seconds on the public endpoint return in hundredths of a second on my local (low spec) server, and the comparative performance to the aforementioned RDBMS solutions is not to be sniffed at.

To handle the typed string literals from OpenCalais, I built a custom dbpedia lookup service (using sparql over the aforementioned Virtuoso + dbpedia setup) which tries to unambiguously determine the identifier for a string literal, if it is known; the results are pretty good and I'd safely say that it gets it right in 98% of cases. This essentially turns the remaining unknown string literals in to known Linked Data URIs, and as a side benefit gives the correct full Name for the thing identified along with the correct casing and obviously much more linked data.

Remaining now the demo has a few OpenCalais semantics which are still unknown, but we know the Type and have a name for the thing; and as URIs are given to things that can be Named, I simply mint my own uri's for these and specify the OpenCalais identifier as a "seeAlso" (to be future compatible with a time where they do associate there own hash uris through to linked data).

At this point the demo has all of the Primary Subjects and Related Subjects determined and where possible linked through to additional LinkedData and human readable web documents about the subjects.

Categorization

This is where the script comes in to it's own and really leverages virtuoso, up till this point it's all been about cleaning, validating, looking up, associating and suchlike.

Given that we now have linked data HTTP URIs for all the subjects we are dealing with, and in all Primary Subject cases we also have dbpedia.org URIs the demo can start to use some of Virtuoso's more powerful features. First point of call is to get the Category intersection of all primary subjects (including the inferred categories!) via a slightly complex transitive sparql query over the dbpedia dataset. From here the demo calculates a set of primary categories which the text is related to, then it finds the general category intersection (again including inferred categories) between the primary categories, and the primary subjects. with the results returned is a wealth of numerical information which the demo dually considers and can then infer which are the General Subjects and the Categories for the text.

At some point I'll cover this part of the script in more details and give some virtuoso specific transitive SPARQL queries for you to use in your own such creations, but for now the above will have to do.

Conclusion

This extractor demo is something I've been working on and trying to achieve for about 5 years, and whilst it is still early days it's the first time the technologies have been available to both make it possible, and to utilize the results correctly to achieve what I'm aiming for overall.

The overall goal is to create a system which allows users to simply drop in content, and the system "files" it in the correct categories, lists it under the correct subjects and interlinks it with other resource via typed links such as "related resources" and looser resource lists of "also mentioned here", further benefits of such a system are that you can accurately figure out what readers are interested in and promote new content to them, you can give users the option of content streams where they can watch specific subjects or combination of subjects to be notified of their "ideal" reading. On the flip side you can also identify users and contributers interests and expertise, and correlate these together (with geo-location) to suggest others users who they may wish to collaborate with, other organisations doing the same work in the same fields and many such uses. In reality I have much of this implemented in a site I've been working on for the last year, which is just being rolled out again, and the system works extremely well with huge benefits to all involved, the site you see deals with climate adaptation and both provides a service to the general adaptation community where they can share and find knowledge, and more importantly serves organisations working on critical issues by letting them see which people / organisations / projects are doing what, where and allows them to both co-ordinate efforts and perhaps more importantly not duplicate efforts and waste resources where it counts most. This has a positive impact on the worlds poorest nations and those suffering people who these organisations are trying to work with and help.

Back to the demo, and with the context described, the extractor.data.fm demo is a quick UI around an API which is in many ways the backbone of the aforementioned system. The API is used in a semi-automated way, where the data returned by it is verified in a UI by the content author / admins who remove any unambiguous data and then hit save, from there everything is automated again and the system functions as above.

I'm unsure whether this kind of system will ever be able to be fully automated (or whether its wise to allow this) as certain scenarios just can't be covered yet, a real life example of this is an initiative called "TEA", ambiguity at this level, and with entities which are unknown to systems or even the web of data, will always be an issue at some point, as things progress it may be they are only ambiguous once, on their first discovery, but that is still once; hence why this may always have to be a semi-automated process.

Personally I find this somewhat inspiring, out of all of it's features the thing that I find most interesting is using human power to rapidly "link" data together.

Here's a very quick look at the human process involved:

1. Assign the subject of the Human Flesh Search.
2. Send out humans to find data about that subject, on both the web and in the physical world
   • When the information is on the web link to it and perhaps highlight some key points in an abstract
   • When the information is in the physical world identify it, and describe it.
3. Correlate all data together and reference it to the subject.
4. Manually cleanse the data to weed out incorrect / wrongly placed data

If this isn't a huge human powered linked data generating and cleansing machine then what is?

IMHO an implementation to cater for this (in early stages) would be extremely simple, for example consider the following:

• The subject of the flesh search is assigned an Identifier (perhaps under the guise of a tag - eg flesh:the_subject)
• A simple interface is made, perhaps a tiny browser extension or toolbar button, which when clicked associates the current web page with the flesh:subject (no doublt by quickly sending the URI of the page as a get parameter to a server, at which point a single triple flesh:the_subject predicate uri is stored)
• For offline resources a simple UI is made to enter in some data (back end obviously stores data cleansed and associated w/ flesh:the_subject)
• Another simple UI to expand or remove information and "links".

Certainly running this as social style web app would be in order, but would require minimal work from what I can see, and serve as a model for a human powered mass linked data generating machine.

nb: you could go wild with this, sponging data and uri's submitted through various web services, now is a good time to stop I think.

This may be overly obvious, but just in-case I thought it needed said :)

Here's a question: are GET and PUT symmetrical? Perhaps my question is a bit out-of-band, because the context of my question is really about the symmetry of content negotiation. Implicit in RFC 2616 section 14 is the existence of a (potentially) wide variety of alternate representations that may be accessed via the HTTP/1.1 request header fields; in the world of linked data these are useful for differentiating between text/html, application/rdf+xml, text/rdf+n3, etc.

So maybe the heart of my question is this: in a linked data world where conneg is alive and well (and assumed), what should be the correct interpretation of RFC 2616's (if) the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server? If I can GET a resource to the resolution of a MIME type, should I not expect to PUT to that same resolution as well? Or, if during a GET the server responds with a list of Alternates, shouldn't I expect to PUT using any of those choices?

Readers familiar with MIME-typed disseminators in the digital repository world (think: Fedora) might think of this as a question about MIME-typed "ingestors"; it is a similar issue: instead of requesting a particular manifestation of the object, this is about updating a specific manifestation (possibly updating the whole).

It's a very good question, and I'm perhaps a bit out of my rank in answering, but to me it seems easy (perhaps too easy) to answer... here go's:

You can request a GET on anything with an HTTP URI.

HTTP URIs can identify anything, however for the context of this let's limit URIs to identifying three distinct things:

1. Stored Hypermedia (digital documents, audio, video, text files ... any "file" physically stored on the server and web accessible.)
2. Web Services (a data-accepting process, a gateway to some other protocol, a separate entity that accepts annotations ... Nota bene if you are still reading then you know what I'm referring to so no need to be pedantic on my choice of terminology)
3. Things (the sky, dave's car, me ... and in this context not hypermedia or web application endpoints)

Let's look at what we can successfully PUT. RFC 2616 section 9.6 tells us:

The PUT method requests that the enclosed entity be stored under the supplied Request-URI ... the URI in a PUT request identifies the entity enclosed with the request ...

We can derive from the above that only "Stored Hypermedia" can successfully be PUT; and thus we cannot successfully PUT a "Web Service" or a "Thing".

Nota bene I'm assuming here that you (the reader) already knows all about CONNEG, Linked Data and the multiple questions which have arisen on how to handle content negotiation, especially with regards RDF and alternative representations.

In the Linked Data world we use the RDF data model extensively. We describe things with statements, each statement is a subject-object-predicate expression which we refer to as a triple; strap enough of these triples together and you have a description of a thing. This is our RDF.

To pass these descriptions around we can serialize our RDF statements in a variety of machine readable formats application/rdf+xml and text/rdf+n3 amongst others.

An RDF Document is where we persist one of these serializations in document, id est Stored Hypermedia.

So to store an RDF document we would logically use PUT, and then GET it later, or perhaps DELETE it. We certainly wouldn't POST to an RDF Document, anymore than we would POST to a GIF image! When thinking about an RDF Document think of it as Hypermedia, exempli gratia an AVI, JPEG or WAV, and treat it as such; a single document, in a single format.

RDF is not one of it's serializations, and it most certainly isn't an "RDF Document".

A major factor which compounds confusion in regards to content negotiation is the Web community's fixation of thinking about the response to a GET as if it were Stored Hypermedia, especially when the mime type associated with the returned entity is something like text/html or application/rdf+xml.

In common language what you are reading is a "web page", infering that it is a Document and Stored Hypermedia.

In reality what you are viewing is an entity returned by a GET request to a Web Service, and that entity has a mime type of text/html. What you are reading is actually just some data I input in to a database via a POST to a CMS (wordpress); there are other things here too, presentation data, navigation on the right and so forth. Leave a comment and the data I entered will stay the same but the entity returned when you next GET this URI will be different. This certainly is not Stored Hypermedia (as we defined it above).

Considering the conneg questions, ask yourself "are these Alternatives Stored Hypermedia or simply entities returned by a web service?". I'm willing to take a punt here and say that your answer will be the latter. Which means that you'd be getting the data in to your system via a POST to a web service. and not a PUT.

Further, if you think about the "RDF" you would no doublt be posting to create these alternatives, it may well make sense to think of it as POSTing RDF in a serialized form which the Web Service accepts. The Web Service will then (all going well) persist this RDF, or the triples, in something like a QuadStore. This serialized RDF is not an RDF Document, it's just serialized RDF in a request entity, just like any other data. Thus think of serialized RDF like json, base64 encoded strings, the egg in ?name=egg&val=shell; it's "just" data.

All of the above is driven home when you consider HTTP URIs that identify "Things". You can't send the Thing in an entity, thus if you get any response from a server when you HTTP GET the URI for a thing, then that URI must be serviced by a Web Service (as defined above).

And now that you know it's a Web Service logic would dictate that you should POST back to it...

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: - Annotation of existing resources; ...

Answering the questions!
After all of that, on to the questions.

• are GET and PUT symmetrical?
  Only in the context where the URI requested identifies Stored Hypermedia.
• If I can GET a resource to the resolution of a MIME type, should I not expect to PUT to that same resolution as well?
  No as by this point you know that the URI/MIME combo you requested definately does not represent Stored Hypermedia (a Document).
• Or, if during a GET the server responds with a list of Alternates, shouldn't I expect to PUT using any of those choices?
  Not expect, as you have no way of knowing whether each URI returned identifies Stored Hypermedia, a Web Service or another Thing. With every new URI the cycle starts again.

Please don't take any of this as gospel, it's all IMO. I do at least hope it makes sense though, and if it doesn't please do correct me asap :)

I've chosen the rather old RFC 2616 (1999!) at this time rather than the upcoming HTTPbis because I feel it's important to know where you are coming from, and whilst many things about the Web of Data feel new, they are really age old principals and technologies which have never been used to their full potential. Further you won't be able to appreciate the refinements in HTTPbis if you don't know what it's refining.

Virtually everything from here on is just a snippet/quote or paraphrase of the RFC. Let's start with a simple one:

Why use HTTP?

HTTP is an application-level protocol for distributed, collaborative, hypermedia information systems. ... HTTP allows an open-ended set of methods and headers that indicate the purpose of a request. ... HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems ... HTTP allows basic hypermedia access to resources available from diverse applications. source

I do fully recommend reading the entire RFC and the new HTTPbis, most questions can be answered by returning to these documents and reading what they say (it's all in the detail); here's some more info gleaned from the RFC:

The difference between POST and PUT, URIs as Identifiers, and URIs to identify more than just documents.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended .. source

Using POST RESTfully for more than just form data.

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: Annotation of existing resources; ... Extending a database through an append operation. The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that ... a record is subordinate to a database. source

What to do if something is created as a result of a POST request.

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header. source

When to use a PUT request?

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. source

How to handle a PUT

If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server.

If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent. source

if extra headers were sent?

Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT. source

and what if I want to save it somewhere other than the URI specified by the client?

If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response. source

and if the PUT can't be done..

If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. source

can I use PUT with server side versioning?

A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version ... a PUT request on a general URI might result in several other URIs being defined by the origin server. source

how would I let a client know I implement server side versioning when they PUT?

If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent.. source

200 indicates a message body in the response ;)

and DELETE?
well it's short so you may as well read it all..

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity. source

note that a response can be 200, meaning you can return a response message (like i have X other versions here [list] or delete them all by clicking here [form input which POSTs to a service] ), or an RDF response that can be interpreted by a client to do the aforementioned :)

but can't I tunnel all actions through GET?

Safe Method .. GET .. SHOULD NOT have the significance of taking an action other than retrieval! source

edit: removed small section about URI vs URL! Do however see the comment from Michael which links to more information on the subject.

Thanks for reading :)
There is much more information in the RFC, but those were some nicer points I found useful and relevant to current Web of Data topics & discussions.

Sounds melodramatic but the whole point of this text is to explain in real terms the effect it'll have on the every day web worker; the web developer, web designer, seo expert, internet marketer etc. So that you, my current or future friends and associates still have a job in a couple  of years; and I researched it so that I would still have a job in a few years (+ because I love this stuff!)

A bit about Linked Open Data (LOD).

LOD can easily be a huge, scary and new thing, overwhelming in so many ways with all this talk of a cloud, billions of bits of information in some part of the web that is separate to "us"; take one look at the diagrams of the linked open data cloud and you'll see those academic acronyms of scientific organisations, future thinking global entities publishing their specialised data - nothing about you and me with our little blogs, and moreover nothing about our clients websites.

Sure it's about getting massive amounts of data on the web, linked and open for use, but it's different to how you expect :)

Linked Open Data is simply about making the info we already put on the net (like this post) machine readable as well as human readable.

It *IS NOT* about creating some system to dump everything from our database in some weird format for a machine to read somewhere.

It *IS* about wrapping the data on a normal page in a bit of markup so that a computer knows what it is.

If you're writing about london you simply add a tiny bit of markup that says 'about="http://en.wikipedia.org/wiki/London"' - honestly that's it in real terms, the user reading your page knows its about London, England - and now a system like google knows that it's definitely about London, England too. In most cases though it's simpler; it's a case of saying this article is titled "x" and made by person "y" - that alone makes a huge difference to the net.

How LOD will change the web.

More Links! We're currently in the age of search, if you want something you search for it, to get more info you search again, and again and so on.

Link trust was at an all time low a few years ago, sure you'd click a navigation link on a site but not a link in a document, because it was probably to a popup, an advert, something you didn't want. Not now though, mainly thanks to bloggers with their in text links to other pages, the world has grown to trust the link again.

Linked Open Data will spawn a massive increase in related data on page, related resources, articles, images, videos and more. And thus many, many more links.

This means that people will search less, and explore more; ever increasingly.

It's unavoidable, and even if a website isn't enhanced with all this extra linked data, odds are the user will have a browser extension or app running that will show all the related information anyway - these technologies are already here and used - adoption *will* grow, no way out of it, change happens.

Info for specific sectors

This isn't the meant to be a full introduction or all encompassing, in fact nowhere near it - if you want the ins and outs of LOD then look elsewhere. This info is for the everyday Web Developer, Web Designer and SEO Specialist.

Web Designers (+ those who work with html)

To be honest I think this change might hit you guy's hardest; you see XHTML+RDFa is already here, it'll be massive soon (and don't go thinking HTML5 will get you out of it, RDFa will be in there too). In short XHTML+RDFa is xhtml as you know it, but with support for embedded RDF information, really it means a few new properties on elements that let you say what they are; in place FOAF, Dublin Core (DC) and the like. Any further description is outside the scope of this document ;)

What this means for you is that as well as having potentially a lot more to display on page (linked data) and lot's of UI challenges, you also now have to cater for this RDFa data in your templates. It's not like other W3C stuff which you can ignore, different to cross browser compatibility, if you leave it out or skip the RDFa stuff then the site will potentially be outside of the LOD network, traffic will drop and ultimately the site may as well not be "in" the web (might be a few years before that though) - so in many ways the end of ignorance and excuses.

You can currently slap out some HTML4, change the doctype, stick on jquery and make it "look" web 2.0 - and people will think it's web 2.0; with web 3.0 (the linked open data based net) you can't do that, it either is web 3.0 or isn't; there isn't a "web 3.0" look, just web 3.0 source.

Drupal 7 has RDFa support out of the box; within the year I bet every CMS & Blog will too; and if you make a new template with the RDFa cut out because you "don't know it", then I'm pretty sure it won't be long before your clients or employers cut you out; and we don't want that.

Further, if you don't - developers will be on your back big time & changing your source; or worse the SEO guys will be ;)

Web Developers
All of you need to know what triples are (subject-predicate-object), and URIs and CURIEs (not your normal URIs, URIs as Identifiers).

If you're going to be exposing data in your systems then you need to get used to mapping database properties through to RDF triples; that a user is a foaf:person with a foaf:name; that tags are ctags and dc:subjects, and that articles have a dc:title (keeping it simple for this).

If you're going to be consuming LOD data then you need to learn a bit more, RDF, SPARQL, Owl, ontologies and a bit more.

And if you want to get "in to" LOD in a big way, then go do it.

SEO Specialists
You need to know what the designers know, and you'll be changing from SEO specialists to data exploration optimizers or suchlike, focus will be on how you can make the data machine readable and get it linked in by the right services.. should be fun!

Further, you'll need to watch for how to get traffic to the sites, as mentioned search engine traffic will drop slowly over the next few months and years; with more focus going on "links" from related pages. As for the diggs & reddits, who knows how it'll effect traffic from them.

Summary

IMHO it's in all of our best interests to just get on with this, it will happen and the sooner YOU do it and convince your employers you have to make this move the better, companies can easily loose clients too if your competition is offering "web 3" and you aren't.

At no point have I seen a tech hit the web which could literally leave people behind if they don't jump on board; it's happened in other industries and now ours (remember VHS?).

The two questions most people / companies / clients will immediately raise..

1] We don't want to expose all our data for reasons X,Y&Z!

LOD isn't about exposing all the your data on the internet; it's about making the data you've already exposed on the internet in a more granular fashion, it's about making that data machine readable.

Presently you may have an article on a page with a title and author credit in HTML, in the future you would still have the same author and title, however they would be wrapped in markup that allows a machine to understand that "Joe Blogs" is a person who is the author of the article, and that the articles title is "I'm scared of exposing my data".

If you consider you're public facing web pages, everything on that page is already exposed, all we're doing here is describing what each bit of data is in a way we can all use.

2] Trust & Junk

One common misconception is that you have no control over the source of the data you pull from the "cloud", and that it could essentially be junk. However this couldn't be further from the truth, what we do is to find a source of data we trust that has their data exposed in a machine readable format, then query it for the exact information we want, and finally include or display it in our own system.

To illustrate, consider you wanted to reference the countries of the world with population in your system. Currently you would have to build  a database table, populate that data with country name and country population, then write some code to display that data. In this scenario you'd probably get the population data from a credible source such as wikipedia (copy and paste it in to your own database).

By using linked open data, you could treat the machine readable version of wikipedia (dbpedia) as your database table, query it instead and again write some code to display the data on you're own site.

You're displaying the same data, from the same trusted source; and you've selected which source you trust; it's not a case of just querying some cloud of data; it's a case of choosing which source(s) you want / trust and querying them.

As an additional bonus you don't need to worry about your information going out of date, as you're getting the data straight from source, the population of each country is updated on your site whenever it's updated on wikipedia.

Further, you don't need to worry about maintaining that list of countries, as in a single query you can pull out a list of all countries with each ones population, as the world grows and changes, so does your data.

Further still! once you've made the move to using some linked open data, all the data you could want is at your finger tips, let's say a decision is made to include 30 different bits of information about each country in your system. Consider that task for a minute - full system change, finding, collating and entering all that data; let alone maintaining it! Well, I'm sure you can guess the next bit, using LOD we can simply expand our original query to include the other bits of information we want, then display it - job done.

That's it.

Good Luck!

nathan

To me, the draw of linked data and the semantic web has always been exploration; the notion that even the most unskilled of publishers should be able to enrich their content via semi-automated software to the standards of a near perfect wikipedia article has always been the driving force. Additionally, content classification, relation, linkage, data centralization and the like are all major benefits which will make a vast difference to the usability of the web.

Search will always be a major part of the internet, at the moment we use search to find content on a specific subject, then search again to find more, and search again to find related or expanded info, help, facts, answers, whatever; however, in the future I hope to see search move to a less prominent role, one where we use search to find the most suitable "entry point" in to the web of linked data - and from there every other piece of related / expanded information is either on page, or a click (link) away.

Some major hurdles need to be jumped before we can get to that stage though, both through lack of organization and lack of appropriate software. Personally I have a mental blueprint / overview of what's needed (imho), and some very specific ideas on the software side, with any luck I'll get a chance to contribute + build some of this, we'll see.

Some thoughts of what's needed from my little brain.

Linked Data Ping
A central service API which is pinged by all software as it publishes information with machine accessible content. (Needed way before (x)HTML+RDFa takes off). Provides a stream of all recent pings to be consumed (xmpp pub-sub?).

Clustered Servers holding a centralized data GUID lookup and proxy.
In essence all resources on the net should be a linked pair of GUID to endpoint, each endpoint should contain a reference to the GUID, and each GUID should be a URI which redirects to the endpoint, endpoints change GUID/URI stays unique. In an ideal scenario when somebody creates a link to X resource or Y document, the publishing/controlling software should replace the endpoint with the GUID instead. This would also enable multiple other services such as centralized pingback, references, statistics etc.

Machine Readable Data Cache.
Together with the aforementioned services a high availability database of cache'd information should exist; in principal this would work by reading the stream of "Linked Data Pings", getting the GUID for the content and then retrieving all machine readable data and caching it. Much like the RDF data exposed through dbpedia, however for everything. Even if only a predefined subset of the common rdf vocabularies was stored and exposed it'd be enough to start, from there all other domain specific ontology could be retrieved by reading the endpoint itself.

Semantic CMS
Ideally we need a new breed of CMS, one that not only has simple FOAF and Dublin Core (~Drupal 7), but also support for full content enrichment using the aforementioned machine services; and provides a simple UI for manually exposing entities, events, facts etc. (Think highlight name in text, mark as Person with Name, system finds guid and builds relevant RDFa and we have another triple of linked data.)

The possibilities from this point are endless; if you're reading this document after all this has been made, then you'd see a whole host of in text links through to more information on each keyphrase, person, entity etc; you'd be aided by auto injection of sources, related reading, comments, further documents discussing the content here, in short you'd be exploring the net one click at a time, linked data all the way; not searching.

In summary (and very much imho), Linked Data is not for searching, it's for linking data - search was invented to address the issue that everything isn't linked, when it is then the link takes precedence again.

My only worry in all of this, is the idea that all rdf triples are fact, and true - already the major search engines are exposing rdfa data in summaries, 5* ratings on products and suchlike, the room for abuse will only get worse.

Thanks Georgi for placing the spark that clarified my current thoughts.

Finally, this isn't a biased opinion in anyway, or an endorsement, but to me openlink virtuoso, dbpedia, zemanta and open calais are leading the way and enabling all of this; together with the hard working folks contributing to the various linked W3C projects and specs. If only dbpedia/zemanta/calais would unify there uri's/guids/endpoints we'd be a lot further along.. (well I would ;).

Regards!

To save everything going to waste, here's a quick list of multiple handy resources which I've found (save you a bit of googling and time).

XHTML + RDFa and related techs.

• Wikipedia RDFa
• RDFa info
• W3C RDFa Primer, RDFa for HTML Authors, RDFa Syntax, RDFa Usage Scenarios
• Google RDFa Support help for webmasters.
• Drupal 7 RDFa Intro, RDF / RDFa Details
• ARC RDF/RDFa Classes for PHP
• OpenLink Virtuoso Open Source Database (RDBMS, ORDBMS, virtual database, RDF, XML, free-text, web application server, file server, sparql, ws-* etc)
• Notation3 on W3C, Wikipedia
• Turtle on Wikipedia, W3C, Authors Site
• N-Triples on Wikipedia, W3C
• GRDDL on Wikipedia, W3C Spec, W3C Primer, W3C Usage Scenarios

Semantic Web Resources

• Semantic Linked Data W3C ESW Wiki
• SOIC, FOAF, SKOS
• SPARQL Query Language, SPARQL Protocol, SPARQL Result Format, SPARQL Tutorial
• RDF Schema (RDFS) on Wikipedia, W3C RDFS Spec, Calais RDFS
• DBPedia Applications, and DBPedia Open Access
• Freebase Developer Docs, Freebase RDF
• Yahoo Term Extraction Service
• Zemanta Contextual Information Service Developer Documentation
• Open Calais Documentation
• AlchemyAPI
• Common Tag

Hopefully that'll be enough to get most people going!