adding some more sugar to rdf

Monday 30 Aug 2010 by nathan | 2 Comments
Filed under: semantic web

Just a quick post to log an idea that's been spinning round my head for a few days.

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!


My Response to 'The Future of RDF Standards'

Monday 30 Aug 2010 by nathan | 3 Comments
Filed under: semantic web Tags: , , , , , , , , , , , , , , , , , , , ,

Thought I may as well post my response to the future of rdf survey that's going on - all of this can be summed up in the comments at the bottom though, that's what I really think should happen.

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.


How javascript will bring on a paradigm shift and a period of unprecedented innovation

Wednesday 4 Aug 2010 by nathan | 2 Comments
Filed under: secrets Tags: , , , , , , , , , , , , , , , , ,

I could burst in to a long post about the importance of universality, or even go in depth about the incredibly liberating experience of writing a library that works on both the client and the server, and indeed the many benefits of both of these combined - but I won't for now.

As we all know, one of the biggest hindrances to innovation in the various areas of computer science is the human brain, and specifically the tendency to think inside, rather than outside the box. There are things we never even consider or imagine because we just can't think outside of what we already know/presume - a small percentage of gifted individuals can, but on the whole, we as humans/geeks/programmers cannot.

To keep this short and simple, let's return to the aforementioned point, with javascript, any libraries you write can be used on both client and server. Great eh, write an AMF parser and it works on both client and server -wonderful.

Now, let's flip the example to a 'shopping basket', you see what we did there? now you've got an ecommerce application on the client side (think about that for a minute, you could put items from any 'website' in your basket, not one, any/all - oh and keep http stateless, and, and..) - here's another one, an authorization protocol like openid or webid - so a server could 'login' to a browser.. - how about an HTTP server in js, yes now it's on the client side and the server side - and when each side is both client and server isn't that just p2p?.

This universality breaks down the barriers of convention, it gets rid of that wall we have between server and client - can you imagine how many 'server side' technologies, libs, patterns and architectures nobody has ever even considered working with on the client side, can you imagine the implications and the period of innovation this will bring on?

Conversely, can you imagine how many client side technologies and libs nobody has thought about putting on a server? fancy using HTML as a data storage serialization and editing it via jquery on the server perhaps?

Maybe you can't imagine, maybe I can't - but fact is it will be possible, and people will start doing it, often just by lack of these assumptions and notions the current generation(s) of programmers have, they won't assume that something we've always used on the server side will be on the client, they'll just do it because it makes sense, and we, well we'll all be astounded.

Make sense?


Recently..

Sunday 1 Aug 2010 by nathan | 1 Comment
Filed under: general Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

On the client side of things, I've been enjoying using jQuery UI and Ext JS, have been really impressed by Protovis, a graphical toolkit (js) for visualization - a quick peruse of the examples like Burton's Antibiotics, Focus + Context or Map Projections and all will become clear, it's a bit like processing but for javascript, and a bit more refined / useful.

There have been some nice examples of combining client and server side js recently, and node knockout is sure to provide many more real soon - if you don't know of node.js I'd recommend taking a look. Also worth noting the realtime client push service, Pusher (for HTML5 WebSockets) - of course there are also node implementations, and here's a nice article with some more details and examples.

I've also been playing with some of google's projects (radar check, you know about the ajax playground ya?), namely Fusion Tables (here's one) which has a full REST API, infact that's what it is, a kinda web db merged with csv merged with RESTful goodness - and you can use them with V3 Maps which gives some really sweet results - like this heatmap of designated beaches on the coast of Brazil. Convergence check, you noticed that protovis can be used with google maps ya?

If there's one app I wish google would opensource, it's Google Moderator for an example see the one for TipJar. Btw, did you see 3D Lego Star Wars running in Chrome with HTML5 (credit to Unity 3D truth be told) - oh, and if you ever wondered how those 3D Lego videos we see on youtube all the time are made, you'll be looking for this.

Generally I'm really admiring ushahidi (projects on github), and especially Swift River and SiLCC - there was a good post on 10 ways to use Swift River which is certainly worth a read. Related, but don't ask why, here's a good post on prediction services which has a few good links. Crossover check, remember earlier I mentioned Fusion Tables w/ Maps V3 and Protovis.

Digital Bazaar have been working on a Javascript implementation of TLS (part2) namely Forge - code on github -explaining why this is such a big deal is outside the scope of this post, but I'd encourage you to look at PaySwarm and Digital Bazaar's fantastic blog which'll give you a good overview of what they're up to. Related and similar, it's worth noting jsSHA - a JavaScript implementation of the entire family of SHA hashes, random.org for all the true random data you could need, Bitcoin a peer-to-peer network based digital currency and amf.js a js implementation of AMF. Also there's the HTTPS Everywhere extension for Firefox.

And in non technical land, I've really been enjoying How to be a Retronaut, it features amazing media from the past, such as Colours of the Rothschilds… which amongst other things has a colour photograph of King Edward VII, taken in 1909 - other recent favourites include the Eiffel Tower being built, the first ever music video (1895) and the instant eye of Jacques Henri Lartigue.

If you haven't seen Hans Rosling's talk on global population growth go watch it now, v recommended - and finally, they figured out what came first, the chicken or the egg..


Just what do you like?

Friday 18 Jun 2010 by nathan | 4 Comments
Filed under: gotcha Tags: , , , , ,

My better half Rachel outlined a problem to me yesterday, which I hadn't noticed before and could be something of an interesting challenge; the case of the ambiguous 'like'.

Here's the setup, a blog post which is a review of a new music album, the post has the familiar facebook 'like' button on there.

Here's the problem, my partner finds that people will only click the 'like' button if they 'like' the album, it's not about the post, the site, the quality of the writing in the review. All points to something wrong in the kudos chain.

It's not just like though, let's introduce a simple '5 Star' rating system on the posts, just what are the users rating, the post, or the album?

Now, let's change the example somewhat, scenario: a well write article about a horrific genocide - hundreds of people saying 'I Like this', as humans we can quickly infer (and somewhat hope) that people are saying they like the article, and not the genocide, but what about a machine.

For your consideration, each web page typically includes multiple distinct things, so we need a way to be able provide users with a way to do 'stuff' which each thing, I like this review, I like this author, this topic is worth noting, I like the primary topic, I've read this and so forth - any semantic web readers will quickly say "ahh problem solved! give everything a URI" (I hope) - but the problem isn't solved, it brings up (yet again) the issue that we need a whole new generation of UX/UI improvements, one 'like' button will not do, when you've got 10-100 things on a page, and different actions for each, this is something that's clearly going to have to be abstracted out from the page and handled in a different way - just how I don't know..

Will leave it there, you can see the challenge..


Design Issue Updates

Friday 18 Jun 2010 by nathan | 21 Comments
Filed under: linked data Tags: , , , , ,

Just a quick note to let you all know that some of the crucial design issues related to social web, cloud storage, linked data, read write web of data and related have been updated by Tim Berners-Lee.

The specific issues are:

I'm yet to disseminate all that's changed, but they certainly are filled out and refined, remember folks the devils in the details!

Quite sure that I'll follow up with a bunch of notes, as will a few others - but for now, there's the heads up that it's time to do a bit of reading.


RDF support in node.js

Tuesday 15 Jun 2010 by nathan | 1 Comment
Filed under: Uncategorized Tags: , , , , , , , , , , , ,

Just a short update, I've ported the latest rdflib from the refactor of tabulator over to node.js.

In other words, you can now use the fantastic tabulator code on the client side, and on the server side - the released code is just a quick port to allow you to get hacking, I'm not planning to maintain it, because I feel it would be far more beneficial to make the rdflib.js code work on both client and server from a single library rather than forking it and loosing the hard work of all involved.

rdflib.js ported to node (was incredibly easy, only had to change a few lines)

A quick example (parsing n3 foaf file and showing everybody with a foaf:name):

var sys = require('sys'), rdf = require('rdflib');
var rdfdata = ''; //some rdf in n3 here; probably a foaf file would be a good idea
var kb = rdf.N3Parser( new rdf.IndexedFormula() , null , uri , uri ).loadBuf( rdfdata );
var FOAF = rdf.Namespace('http://xmlns.com/foaf/0.1/');
var results = kb.each( undefined, FOAF('name') );
for (var i = 0; i < results.length; i++) {
sys.puts( results[i] + ' ' + kb.the( results[i] , FOAF('name') ) + '\n' );
}

Related, I've also updated Sean B. Palmer's FOAF example to work on the clientside with RDF/XML and with N3.

Back to node.js stuff, I've also released a patch which exposes all the details needed for FOAF+SSL in node to node_cryto.js (hopefully it'll get added to the main git repo v soon) - next step is to get a JS FOAF+SSL library working, which shouldn't take too long.


« Older Entries

  • webr3 avatar