I've grouped all the links in to two main sections, and then sub-grouped by how they make sense in my head! :)

Web, HTTP and REST

Roy T. Fielding Dissertation - Architectural Styles and the Design of Network-based Software Architectures Of particular relevance and note are chapters 4-6 (many only ever read chapter 5 and miss the context + summary *needed* in chapters 4 and 6!)

• Chapter 4 - Designing the Web Architecture: Problems and Insights
• Chapter 5 - Representational State Transfer (REST)
• Chapter 6 - Experience and Evaluation

Roy T. Fielding - REST APIs must be hypertext-driven
Discussion on HTML5 and RESTful HTTP in browsers
Discussion on URIs Resources and Switching content types w/ REST angle (v good)

RFC 2616 HTTP/1.1 and the HTTPbis Working Group HTTP/1.1 update in parts:

1. Messaging
2. Semantics
3. Payload
4. Conditional
5. Range
6. Cache
7. Authentication

Linked Data and the Semantic Web

Linking Open Data Community Project
Linked Data Applications
Equivalence Mining and Matching Frameworks
Linked Data Browsers, Mashups and other Client Applications

Dataset Dynamics - On the Dynamics of Linked Datasets
Realizing a write-enabled Web of Data
Web Access Control (WAC) - a decentralized system for allowing different users and groups various forms of access to resources where users and groups are identified by HTTP URIs.
Discussion of the WAC vocabulary
Socially Aware Cloud Storage Design Note
Distributed Social Networking through Socially Aware Cloud Storage from TimBL
AWWSW - "Architecture of the World Wide Semantic Web" Task Force

SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs
A Linked Data Frontend for SPARQL Endpoints
RAP - RDF API for PHP V0.9.6
Inav the Terrible - An idea for posting RDF through HTTP.

Talis Changesets
Triplify Update Vocabulary

skos as atom

RFC 4287 - The Atom Syndication Format
RFC 5023 - The Atom Publishing Protocol
AtomPub Tombstones - The Atom "deleted-entry" Element
RFC 5005 - Feed Paging and Archiving
Versioning Link Relations - Link Relation Types for Simple Version Navigation between Web Resources

Named Graphs, Provenance and Trust
Accessing Site-Specific APIs Through Write-Wrappers From The Web of Data
Provenance Information in the Web of Data - LDOW 2009 paper
Using Reification To Extend RDF (historical reification approach)
RDF Policy-based URI Access Control for Content Authoring
The Open Provenance Model Core Specification (v1.1)
W3C Provenance Incubator Group

History of the Web 1945, 1980 through 1997 on W3
LEIRI - Legacy extended IRIs for XML resource identification The type of "URI" used in xml:base
CSHALS 2010 W3C Semanic Web Tutorial
Mindswap online RDF Converter
W3 online RDF Validator

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.

Further the code isn't running on a solid server where the environment is controlled, and where you can simply throw more processors and memory at a problem to make it go away, the code is being run on differently specified machines almost every run, in a different client and in different versions of player.

To compound this unique situation the virtual machines (relatively) poor performance comes in to play.

Why is this good?

It has spurred a good percentage of ActionScript developers on to look at more advanced levels of code optimisation, to consider factors which are simply ignored and overlooked in other languages, to work with (and create) other technologies in order to push performance to the max; indeed even to hack the virtual machine to bits then create custom compilers and optimisers.

Libs and frameworks from PV3D through to Flex, projects such as haXe, Apparat and Alchemy; not to mention the wide array of technologies from AMF to RTMFP - this list goes on (and on).

There are 3 types of coders: bad coders, normal coders and ultra coders who's skillsets and level of understanding are far and beyond that of the normal coder; what I'm trying to get at here, is that the ActionScript challenges outlined above create an environment where a higher percentage of coders can grow in to ultra coders, than in any other language I know.

The Flash / ActionScript pair gives both designers and developers the notion that anything is possible - and this spurs them on to the push boundaries of what can be done; that kind of thinking sticks with people, they carry it on to other languages, platforms and communities; bringing inspiration and forward thinking to the web of humans.

Context: Really enjoyed reading this post: The Advantage Of ActionScript from Joa, in particular I'm glad that he mentioned "Poor Performance" as an advantage. The above post leads on from Joa's to give some of my own thoughts on why we all owe ActionScript and Flash a little something.

Very brief intro: SPARQL is a fantastic query language which works over RDF and thus Linked Data, Virtuoso amongst other things has a powerful QuadStore which can be queried via SPARQL, and Virtuoso's implementation of SPARQL + the extensive suite of extensions they have implemented makes it the most usable and powerful query langauge available (again, in my honest opinion). In short this combination was enough to make me drop normal RDBMS systems and never look back.

Rather than rambling on about how fantastic it is though; here are some Virtuoso specific sample SPARQL (+GEO) queries, which should hopefully wet your appetite and give you some inclination of what can be done.

Basic Geo Lookups

Things within 20km of New York City : RESULTS
SELECT DISTINCT ?resource ?label ?location
WHERE
{
<http://dbpedia.org/resource/New_York_City> geo:geometry ?sourceGEO .
?resource geo:geometry ?location ; rdfs:label ?label .
FILTER( bif:st_intersects( ?location, ?sourceGEO, 20 ) ) .
FILTER( lang(?label) = "en" )
}

Distance between New York City and London, England : RESULTS
SELECT (bif:st_distance(?nyl,?ll)) as ?distanceBetweenNewYorkCityAndLondon
WHERE
{
<http://dbpedia.org/resource/New_York_City> geo:geometry ?nyl .
<http://dbpedia.org/resource/London> geo:geometry ?ll .
}


Querying Time and Space

All Educational Institutions within 10km of Oxford, UK; ordered by date of establishment : RESULTS
SELECT DISTINCT ?thing as ?uri ?thingLabel as ?name ?date as ?established ?matchGEO as ?location
WHERE
{
<http://dbpedia.org/resource/Oxford> geo:geometry ?sourceGEO .
?resource geo:geometry ?matchGEO .
FILTER( bif:st_intersects( ?matchGEO, ?sourceGEO, 5 ) ) .
?thing ?somelink ?resource ; <http://dbpedia.org/ontology/established> ?date ; rdfs:label ?thingLabel . FILTER( lang(?thingLabel) = "en" )
} ORDER BY asc( ?date )

Historical cross section of events related to Edinburgh and the surrounding area (within 30km) during the 19th century : RESULTS
SELECT DISTINCT ?thing ?thingLabel ?dateMeaningLabel ?date ?matchGEO WHERE {
{
SELECT DISTINCT ?thing ?matchGEO
WHERE
{
<http://dbpedia.org/resource/Edinburgh> geo:geometry ?sourceGEO .
?resource geo:geometry ?matchGEO .
FILTER( bif:st_intersects( ?matchGEO, ?sourceGEO, 30 ) ) .
?thing ?somelink ?resource
}
}
{?property rdf:type owl:DatatypeProperty ; rdfs:range xsd:date } .
?thing ?dateMeaning ?date . FILTER( ?dateMeaning in( ?property ) ) . FILTER( ?date >= xsd:gYear("1800") && ?date <= xsd:gYear("1900") )
?dateMeaning rdfs:label ?dateMeaningLabel . FILTER( lang(?dateMeaningLabel) = "en" ) .
?thing rdfs:label ?thingLabel . FILTER( lang(?thingLabel) = "en" )
} ORDER BY asc( ?date )

Transitivity and Inference (v5 compatible)

Finding the shortest route between two "things" (HTML and XML in the example) : RESULTS
SELECT ?route ?jump WHERE
{
{ SELECT ?x ?y WHERE { ?x foaf:page ?xpage ; ?predicate ?y . filter( isURI(?y) ) } }
OPTION ( TRANSITIVE, T_DISTINCT, T_SHORTEST_ONLY, t_in(?x), t_out(?y), t_max(10), t_step('path_id') as ?path, t_step(?x) as ?route, t_step('step_no') AS ?jump )
. FILTER ( ?y = <http://dbpedia.org/resource/HTML> && ?x = <http://dbpedia.org/resource/XML> )
}


..and all routes between the two "things" : RESULTS
SELECT ?route ?path ?jump WHERE
{
{ SELECT ?x ?y WHERE { ?x foaf:page ?xpage ; ?predicate ?y . filter( isURI(?y) ) } }
OPTION ( TRANSITIVE, T_NO_CYCLES, t_in(?x), t_out(?y), t_max(5), t_step('path_id') as ?path, t_step(?x) as ?route, t_step('step_no') AS ?jump )
. FILTER ( ?y = <http://dbpedia.org/resource/HTML> && ?x = <http://dbpedia.org/resource/XML> )
}

Traversing Ontologies and (Sub)Classes; all subclasses of Person down the hierarchy : RESULTS
SELECT DISTINCT ?x WHERE
{
{ SELECT ?x ?y WHERE { ?x rdfs:subClassOf ?y } }
OPTION ( TRANSITIVE, T_DISTINCT, t_in(?x), t_out(?y), t_step('path_id') as ?path, t_step(?x) as ?route, t_step('step_no') AS ?jump, T_DIRECTION 2 )
FILTER ( ?y = <http://dbpedia.org/ontology/Person> )
}

Free text search, scores and IRI Ranks (v5 compatible)

Searching over labels, with text match scores and additional ranks for each iri / resource : RESULTS
SELECT ?s ?page ?label ?textScore ((?s)) as ?iriRank WHERE {
?s foaf:page ?page ; rdfs:label ?label . FILTER( lang(?label) = "en" ) .
?label bif:contains 'adobe and flash' option (score ?textScore ) .
}

Virtuoso 6.1 (Open Source Edition) released. For features & bug fix details see: link

A few months ago I upgraded my pc, part of which included adding an Asus GeForce 9600 GT; shortly after installing, the Fan on the graphics card started to make a most irritating grinding noise. I found that if I knocked and tilted my case a few times I could get it to stop grinding & quieten down (the hit-it fix). Over time this grinding has become more frequent, to the point that it's almost non-stop; and so that it vibrates the case and thus you can hear it all through the house. It's been driving me insane because everytime I get it to stop, the *slightest* of movements starts it going again, which includes me moving, somebody walking past, infact anything. This weekend it's been especially bad, in-fact I've felt like throwing the f'ing thing out the window; finally this morning I had enough and thought I have to get a new fan for this thing.

Searching the internet found me no replacement fans, which meant I was looking at sending the card back to get it fixed (and thus missing out on work), buying a full new cooling set, or buying a new card - the last two options would have led to pc-murder as seriously this noise goes right through you. Thus after running out of options  I tried to fix it.

How to fix a noisy computer fan:

1. Remove the fan from the computer (in my case this meant removing the graphics card and unscrewing the plastic cover and fan).
2. Once you have the fan removed, remove the stickers from it.
3. On one side you'll notice a small recess with the end of a small metal pin on it (the bit that holds the fan together, and which the fan spins on)
4. Take a small, toy plastic soldier and chew off the arm (or rifle butt it if has one).
5. Take the cap off a bottle of Filippo Berio Extra Virgin Olive Oil and fill said cap approx half full with said olive oil.
6. Dip one end of the plastic arm / rifle in to the olive oil, then dab the smallest of drops on to the small metal pin in the recess of the fan (from step 3)
7. As you do step 6, gently pull the two parts of the fan about 0.5mm apart and turn the fan clockwise and ant-clockwise.
8. Repeat steps 6 & 7 until you feel the oil has worked its way in and loosened it, "oiled the fan".
9. Be very careful not to swamp the thing with oil, it's an electronic part and you'll break it.
10. Reassemble what you took apart in step 1.

I do believe the specific brand of olive oil, or even the fact it's olive oil isn't of significant importance, likewise the soldier arm / rifle could be anything small that's good for poking.

As an extra bonus, my graphics card is now running 20 degrees cooler when idle :)

Short version:

1. Oil it

Disclaimer:

This worked for me, I'm most pleased, if it doesn't work for you or you break something, don't blame me - but it might be worth a try.

Regards!

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!

Much of the work has been dumbed down to repetitive, narrow scoped projects that really take little to no "developer knowledge".

I'm sitting here racking my brain, how to find a way to spend 2010 learning further and putting all these good things in to practise? I'd love to spend a good chunk of the year piecing together all these new tech's to create something great; and preferably with some of the ultra skilled developers I know - the scope is incredible, the boundaries are virtually limitless, and moreover, the technologies are there for the picking!

Surely, somewhere, there is a business man sitting racking his brain, fed up with the same old sites every one has, aware of all these new techs, great API's, and with the notion that something great can be created; posting job offers and hunting down the right developers for the task?

I just can't grasp that with all the forward thinking companies and people out there pushing boundaries, that nobody is wanting to take advantage of that and tie them all together.

So here's the problem; how to pair the two? how do we match up to the right companies & businesses. In fact.. how do I find the right people who want to exploit all of this?

Link up the goodies available from the semantic web, with the tech advances in streaming technologies, via a whole host of API's, using the latest languages to target multiple platforms; polish it all off with the latest in graphical interfaces and develop a realtime monster application to be proud of.

I'd love to list the tech's involved, but the list would be 100+; and more to the point - without a set project description to mesh this all together, we just don't know. But.. anything is possible.

Developers can you think of a way to break the masses in to the next generation of the internet?

Companies & business men, can you think of some projects to get us there?

The next stage of the net is sooo close, yet so far, all we need to do is grab it and go - I know there's a lot of forward thinkers that read this blog.. rack you're brains for the good of us all!

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!

update:
I've been off for a week after finishing a project and moving house, in that time this domain dropped and just prior to that appeared to get 20k+ reads which is a bit omg. Anyways many comments all over the net, and certainly on reddit (comments here) - and thus just to clarify, the entire content of this post is purely a note to myself, and to help me in those times when you can't get going in the morning or such like.. in no way am I suggesting you don't plan or do things properly whenever you can - this is literally just some ways of getting through the day. Thought I'd made that clear and most people got it ;)
end update:

This one is more for my own reference, but sharing anyways as it may help others. In numerous scenarios it is really hard to "get going" when you're trying to code, particularly under the following circumstances:

* You haven't started coding till late(r) in the day
* Emails, Blogs, Social networking have taken up more time than expected and/or distracted more than anticipated
* You've just completed a deliverable, milestone or task.
* You're tired!

All of these are virtually daily occurances in the coding world, and here are the methods I've used to get going again.. no particular order, just a list.

Under all circumstance, avoid planning!
Planning is one of those things you can't do unless you are all ready in the flow, whether this is because you've just had a client meeting, a long discussion, or read a full spec - it's not the thing to do to get your flow going, all you'll do is plan nothing, plan badly, or stare blankly at the screen / paper.

Don't read related material to get you in the flow.
This will purely serve to distract you, make you think about doing things differently, doublt what you've done or worse throw you in to planning mode - fact is you won't be planning "your" app though, you'll be planning "some" ideal app or scenario.

Pick the smallest task, whether complex or not, and just do it!
Doesn't matter what it is, so long as it's coding a little part of the app, or modifying part of it, then it'll do. It could be adding an extra field to an object or table, popping in some validation, anything small and simple. It really doesn't matter if you do it right or wrong; you're not doing it to sign off a task, you're doing it to re-aquaint yourself with your system, by the time you've been through X lines of code you'll be back in work mode and firing on all cylinders, well on your way to getting zoned.

Music, Headphones, Repeat.
You'll know the genre that suits you, personally I find repeating an album or even song fades me in to the zone and keeps me there. The repetitiveness of the tune keeps you there, because just as a phone call can distract you, so can a change in tune to something at a different tempo or worse a completely different genre.

Don't cram!
If you've only got 15 minutes before the next sizable interuption, forget it, don't do anything just chill - make a coffee, smoke, whatever. You're not wasting time you're saving your zone, you can only get zoned a couple of times a day, so don't get zoned for only 15 minutes - save it and get zoned for longer later on.

Speedcode
Why not? as nike say "just do it", if the code has 10 bugs but is finished in half the time then you've done good, that gives you loads of time to fix the bugs, and more importantly you get to those moments where you realise x,y&z need to be changed much quicker. Not only that, but would you rather have a week to go and have a list of 80 bugs, or a week to go and 2 major deliverables a week overdue..

Communicate for no reason.
Often a major focus is simply talking to somebody else on the same project as you, whether its the client or a workmate, and the more stressed they are the better, they'll not only blast you with things but their urgency / stress will often convey straight over to you and focus / zone you instantly.

Do the thing you know, not the thing you don't.
Inline with "don't plan" and "pick the smallest task", always pick something you can already do (if possible), as with everything else, the things you don't know are much easier when you're already zoned, not only that but you'll be more focussed when doing the thing you don't know so less likely to over spec / over code it.

Don't code other things!
nothing on earth will kill your project like working on something else, every minute you spend on another script or app is like an hour lost on what you should be doing, and with every minute that passes you're getting closer and closer to utter project failure - and hence why most open source projects are dead.

Remember, the key to forced coding is just to get you in the zone, and ultimately boils down to just getting stuck in there with some lines of code on your project.

Works for me anyways [most of the time] - if anybody has anything to add (constructive) then please do!

Regards - nathan

A lot of work is always done on the code optimization side of things, and recently this has hit the ActionScript world; most notably (imho) with haxe and TAAS - both of these things have a lot of optimizations improving the compile process, which means our code ultimately runs faster :) inlining, code reduction, dead code elimination, flow optimization etc.

Ultimately, the fastest compiled script will always be a flat set of vm operations with none of that expensive method calling and instantiation, and lets remember that OO is pretty much a syntax we use to develop, haxe makes it clear with its common syntax which compiles to multiple vm targets.

So, here's the background question - why do our actionscript classes compile to compiled classes?, all the code from those nested called methods could be factored right the way back in to one big method, and a single class, then heavily optimized - imagine the speed gains.

Thinking further, implementing doesn't appear too hard - i mean all your going to need to do is essentially copy the code from one method and place it in the calling method at the correct position(s); any duplicate code introduced would be offset easily by the amount of code cut out by removing all those un-needed classes and methods - further the unused classes and methods would be lost; and the final chunks of code could be optimized to hell and back.

The only problem i can see is that we need compiled classes to distribute or pull in remotely sometimes, which is why I'd propose a simple "Service" interface (or suchlike) the point of which is that any class marked as a service class (or gateway?) would keep its class structure and public methods.. after all everything behind the public methods is of no concern to any other part of the system.

If you consider a flex application for example, or that class which uses circa 5% of all the large libs included in the final compiled script.. not to mention the additional optimizations that could be made on the big blocks of code in each method!

So that's it, Flat Packing - the ultimate optimization?

ps: quite sure this applies to most OO languages not just actionscript ( haxe guys will agree I'm sure (I hope) ).

Regards!

Something all of us developers realise but it doesn't always smack home until certain scenarios arise - The Wall (as I'll call it for now) is the virtual line behind the UI which is where the developer / client separation of concerns occurs. The client wants to see one thing on a UI, click a few buttons, hit a few keys and see the UI change to another thing, this change indicates that we as programmers have done our job, behind that line is generally our concern.

Here's the scenario.. a few weeks back "we" started a full 3 tier app, the Applcation tier consisted of the three big layers, service layer -> domain model layer -> data source layer; everything implemented by the book with transfer objects, DAOs, business objects, a full language extension lib, utils, everything coded to interfaces and using factories.. you get the picture.. a lot of code. On the presentation tier we had single UI consisting of a full MVC framework with all the magic and goodness, the models of which talked to the service layer of the application tier (as it should).

A couple of hundred hours later we get our first full end to end done, a simple FAQ system.. possibly the most overkilled FAQ system ever, but still a great end to end test. This is where the wall becomes clear, because for all of that the client only saw a simple FAQ system.

At this point, as a developer you have to ask yourself why.. the FAQ system could have been developed in circa 1 hour using a few lines of PHP and simple mysql database + some echo's.

I don't have an answer to this, and don't think there is one... because if you think about all the immediate arguments for doing it the "proper" way.. maybe even the java way - you still have to think, what is more maintainable a few hundred files and a complex architecture full of design patterns, or three lines of PHP a "n00b" could maintain.

More over.. ultimately those few lines of code you could make the application with are pretty much the same few lines of code which aren't reusable when using the full application approach.

Finally you ask yourself.. if a good programmer introduces about 2.5 bugs per 100 lines.. then what requires more long term maintenance; 100 lines for a full FAQ system or 100 classes with 100 lines each.

Just a thought, that won't go anywhere - because i get paid to make these big applications, but when the pressures on and I've got a 3 hour deadline I do the 100 line thing.

no response needed, simply questioning oneself (again)

The change isn't a massive one, but does speed things up - simply it replaces the old:

important: turns it this runs slower if the z-val is outside of the range 0-1; a LOT slower, so don't use!

sortArray.sortOn("screenZ", Array.NUMERIC | Array.DESCENDING);

with the new:

sortVector.sort( function compare( x : SimpleZSortVO , y : SimpleZSortVO ) : int {    return x.screenZ - y.screenZ; } );

and here's the source all nicely zipped up, you should be able to simply drop this in your fp10 swfs as a replacement for the older version,

Thanks to Ralph for one opensourcing it and two giving me a heads up that its okay to "upgrade", sure it can still be made faster still with a bit of thought.