Re: Requirements for a possible "RDF 2.0"

I forgot to mention, there is no downside to the extensions performance
wise either - it is for the tools to optimize. I know I won't get much
popularity by saying this, but even named graphs should be an extension
- being expanded to triples using reification when serialized to a
syntax which doesn't support them. The triplestore supporting named
graphs wouldn't contain the reification triples (well it could have if
it wanted to), but hold it in optimized named graph structure.

Best,
Jiri

On 01/18/2010 11:55 PM, 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.
> 
> 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.
> 
> 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.
> One of the extensions could define terms for expressing availability of
> the extensions in various tools (DOAP-style mixed with software
> repositories).
> 
> Anyway this isn't stripping down of the RDF. The "ground level RDF" +
> some basic stack of extensions (more or less what is RDF today) could be
> called the RDF, so people don't go reinventing the wheel again, not
> noticing the extensions.
> 
> 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.
> 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.
> 
> Best,
> Jiri
> 
> On 01/18/2010 10:31 PM, Kjetil Kjernsmo wrote:
>> On Monday 18. January 2010 17:59:26 Pat Hayes wrote:
>>> But how else would you naturally express a property of anything in  
>>> RDF, than by writing a triple? It sounds like you want to not be using  
>>> RDF at all :-)
>>
>> Oh, yes, I do! We already have precedent: datatypes and languages are 
>> "properties" of literals, and I think units should be done in much the same 
>> way, unless we find a way to do it in a more general way, that is also 
>> simple enough in practice.
>>
>> Best,
>>
>> Kjetil
>