W3C home > Mailing lists > Public > semantic-web@w3.org > July 2010

Re: Show me the money - (was Subjects as Literals)

From: Nathan <nathan@webr3.org>
Date: Thu, 01 Jul 2010 17:10:42 +0100
Message-ID: <4C2CBE02.7010205@webr3.org>
To: Jeremy Carroll <jeremy@topquadrant.com>
CC: Yves Raimond <yves.raimond@gmail.com>, Pat Hayes <phayes@ihmc.us>, Toby Inkster <tai@g5n.co.uk>, David Booth <david@dbooth.org>, Dan Brickley <danbri@danbri.org>, Linked Data community <public-lod@w3.org>, Semantic Web <semantic-web@w3.org>, Michael Hausenblas <michael.hausenblas@deri.org>, Story Henry <henry.story@bblfish.net>, Kingsley Idehen <kidehen@openlinksw.com>, Ivan Mikhailov <imikhailov@openlinksw.com>
Dan, Jeremy, Pat, Henry, Michael, Kinglsey, Ivan, ack.. everyone,

Part of me feels like I should apologise for bringing this to the 
mailing list (even though it was inevitable) - this is all getting out 
of scope and the last thing we need is one of the most critical 
communities in what's a mini revolution to be split over such matters.

Valid arguments from all sides, technical and not - but things are 
really getting conflated here, at least from what I originally intended 
to put forward (probably past that and insignificant now).

I respect that everybody has made large investments, time, money, data, 
deployment, training and so forth; but really, non of that need be 
wasted and nobody need change anything that has any impact on any 
investments thus far.

My (personal) concern is really on the 10 year timeline (a bit shorter 
to be honest ;), there are limitations and things in RDF that do, 100%, 
prevent the web of data as a whole from moving forwards - however, 
nobody has to scrap anything.

Simply, define a non serialization specific model that caters for N3 and 
RDF - then let each standard or serialization specify what it 
implements/supports - the point here, and I stress, isn't to break 
anything, but to open it up to innovation and allow the next decades 
worth of hacking to get going

So RDF/XML is perhaps broken technically and doesn't support all these 
things, who cares? it obviously works just fine for a deployment of 
several billion triples, why change it? why not define it as a subset of 
some core model? - I can only see one reason not to, and I hate to say 
it, but some kind of pride that the work done thus far and commonly 
adopted *must* be seen to be 'perfect' - please, don't take that as any 
insult, as none is intended.

There are clearly very strong opinions on both sides, and very valid 
reasons too - there's an easy solution that would keep everybody happy 
and allow all to get on being productive and innovative - why not enable 

In all honesty, if this doesn't happen, I personally will have no choice 
but to move to N3 for the bulk of things, and hope for other 
serializations of N3 to come along - I'd do that today, but you see I'm 
a huge linked data proponent and see almost unquantifiable gains from 
adopting linked data - but if what I do to get a full working model of 
the web of data doesn't qualify as valid RDF at some level and you all 
can't utilize it, then it's a wasted effort and a road to no where - 
this, is the real issue, and many others have hit it, and will hit it 
again and again as time moves on.

Please, do consider, nobody need loose anything here



- :(

Jeremy Carroll wrote:
> I am still not hearing any argument to justify the costs of literals as 
> subjects
> I have loads and loads of code, both open source and commercial that 
> assumes throughout that a node in a subject position is not a literal, 
> and a node in a predicate position is a URI node.
> Of course, the "correct" thing to do is to allow all three node types in 
> all three positions. (Well four if we take the graph name as well!)
> But if we make a change,  all of my code base will need to be checked 
> for this issue.
> This costs my company maybe $100K (very roughly)
> No one has even showed me $1K of advantage for this change.
> It is a no brainer not to do the fix even if it is technically correct
> Jeremy
Received on Thursday, 1 July 2010 16:11:53 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:18 UTC