Re: Requirements for a possible "RDF 2.0"

On Monday 18. January 2010 23:55:38 Jiří Procházka wrote:
> This is what I wish never was introduced to RDF.
> I was told literal datatypes are there for for some semantic reason I
> don't understand, but why we there are language tags is completely
> beyond me.

OK.

> Thanks to this bad precedent we could introduce a special semantics for
> measures (like you wish), time handling, events, grouping, and so on and
> so on into the core RDF spec.

Well, I haven't expressed a wish, I have just thrown a possible way to do 
it, and noted that they way it can be done now is flawed, simply by the 
lack of adoption.

Certainly, I am all for a generalised approach, many important intellectual 
achievements are of that nature, but it can't be just more of what hasn't 
worked. If that cannot be reached, one shouldn't waste much time trying to 
figure it out.

> I hope you realize how wrong this is - no clear line drawn to decide
> what should be in the core and what not. That clear line is what I
> personally would like to come out of the "RDF 2.0".
> 
> I have my opinion on it, which I am ready to elaborate and defend - make
> "ground level RDF" which defines nothing more than triples and literals
> (without datatypes and language tags. Maybe bnodes would have to be
> there too because of semantics.) and build the rest on top of it (call
> it modules, semantic extensions, whatever).
> 
> These extensions would translate to triples so for example "hello"@en
> would translate to:
>   "hello" rdf:type rdflang:LanguageTaggedLiteral ;
>     rdflang:language rfc5646:en .
> (I am for having all-resource-wide owl:sameAs (not only instances) in
> RDF core, thus literals as subject too)
> 
> Plus the extension would define the necessary semantics, possibly using
> a different extension for expressing the axioms (if OWL or SWRL or
> whatever isn't up to the job already)
> 
> Advantage of this modularity is that the tool implementators don't have
> to shoot at a moving target, supporting stability and ease of adoption.

There is no moving target, and there hasn't been for many, many years. Even 
so, important programming languages doesn't even have a parser for the most 
basic formats, much less a well developed toolchain.

I've been following the RDF community for around 12 years now, and been 
developing for 7, and I strongly believe that the problems semweb sets out 
to solve are very important and unique, and cannot be solved well with 
other techniques. Yet, to date, I have not seen one application of semweb 
technologies on the open web that couldn't be solved as good with older 
technologies. The number of developers I know who have tried and abandoned 
RDF vastly outnumbers the people whom I know still make a living from it, 
and big companies that have supported semweb are withdrawing. 

In light of this, I am strongly opposed to the following view:
> Back to you Kjetil - taking human usability in consideration in RDF core
> design is recipe for disaster - a flawed evaluation of its domain, not
> pragmatism. This is what RDF syntaxes (ie serializations) are about.

It seems highly unrealistic to me to develop the perfect serialization, 
have it permeate all of the semweb world, into SPARQL patterns, etc., 
within the timeframe we have before people reasonably can call RDF a 
failure. 

In fact, I think that developer friendliness, based closely of what we 
have, should be the main priority of any further work, and I don't think it 
should be RDF 2.0, just RDF 1.1.


> I am working (slowly) on a serialization which introduces distributed
> macro system, not unlike C preprocessor, for expanding simple
> expressions into triples, so for example instead of:
>   "hello" rdf:type rdflang:LanguageTaggedLiteral ;
>     rdflang:language rfc5646:en .
> you would write
>   ll:["hello"en].
> Not as easy as easy as "hello"@en, but flexible. Anyway, still in alpha
> stage.

Sure, but that's not going to do anything to help in any foreseeable 
future, the impact on all the stuff we already have in SPARQL, for instance 
is too big.


Cheers,

Kjetil
-- 
Kjetil Kjernsmo
kjetil@kjernsmo.net
http://www.kjetil.kjernsmo.net/

Received on Tuesday, 19 January 2010 22:58:12 UTC