Re: Requirements for a possible "RDF 2.0"

On 01/19/2010 11:57 PM, Kjetil Kjernsmo wrote:
> 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.

If the specification is changed, there is moving target. This system of
extensions I described would allow developers to focus on particular
issues, being a much cleanly structured framework than what is RDF
today, which is basically a mashup created by trying to find a
compromise between lot of different people talking about a *very* broad
subject. I am not blaming W3C, they did good job considering what they
set out to do, I just wish they set out to do a bit different thing. :)

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

Now this reminds me of another thing I found bothersome - why wasn't
SPARQL defined as syntax independent as an ontology? Now there are
different attempts for it like SPIN which then will be very hard to map
between them. Triples first, syntax second!

Everyone should view data in any serialization he wants, today this is
limited - you can't just convert TriG to Turtle. With the extension
system I propose you could, since the syntax of every extension would
have triple structure equivalents.

> 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 agree, but this is more work for common developers, to pass on their
knowledge and create RDF cookbooks, then for standardization group.

Best,
Jiri

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