Re: Requirements for a possible "RDF 2.0"

Hi -

I haven't been significantly involved with the RDF community, but have 
taken an interest in RDF, not for describing web resources, but in the 
context of data stored and processed by enterprises. Here's my 2c.

On first looking at the RDF spec, I couldn't understand the reasoning 
behind it, or see why the definitions were as they were - they seemed to 
be completely counter-intuitive in some cases. But, when I tried to use 
it, I found that most of these definitions were sensible and useful. (I 
would make exceptions for containers and reification, which I've never 
needed or - in the case of reification - understood).

I do believe that RDF has serious potential for application to things 
that are described by enterprise data. It may have started with the idea 
that everything should be identified by URIs, but this is not a 
necessary assumption, and RDF is even perfectly usable if you assume 
that nothing has a URI.

It is the only thing that we have remotely resembling an accepted 
standard computer language for describing "things". My impression is 
that use of it is increasing. My recommendation is to leave it 
substantially as it is - perhaps making small changes such as you 
propose - and continue to encourage its wider acceptance.

Danny Ayers wrote:
> 2010/1/13 Chris Welty <cawelty@gmail.com>:
> 
>> I suppose we don't really need to discuss whether we should investigate an
>> "RDF 2.0", but rather what kinds of requirements various RDF users have that
>> they would like to be considered
> 
> Personally I don't think the time is right for an "RDF 2.0"
> (suggesting a major overhaul), though an "RDF Second Edition" (as Jiri
> suggests) may be desirable.
> 
> There's still a large amount of consolidation work needed (notably
> with the recent arrival of RDFa, OWL2 and RIF), and probably more
> significantly there aren't any major technical blocks to widespread
> deployment based on the current specs - i.e. if it ain't broke, don't
> fix it. If there are such problems, then let any spec changes be
> driven by real-world use cases rather than change for change's sake.
> 
> Having said that, there are a few areas that could probably use
> attention given developments since the 2004 specs -
> 
> Out:
> * containers (Bag, Alt, Seq) - quiet deprecation would probably be the
> best bet, supported by clear instruction on how to use Lists.


> 
> * reification - ditto, with named graphs as the modern alternative
> 
> both features can cause a lot of confusion, seeming more useful than
> they actually are
> 
> In:
> * improved support for named graphs - essentially bringing the
> constructs included in SPARQL back into RDF core (including support
> for named graphs in RDF/XML, done in a manner that would be
> backwards-compatible if at all possible)
> 
> * W3C-blessed subsets of the model & syntax - on the model side, e.g.
> a profile that excludes blank nodes, on the syntax side e.g. a profile
> that uses the triple-shaped rdf:Description style of RDF/XML
> (basically I reckon it's too late to make breaking changes to RDF/XML,
> but it still remains a significant hurdle for newcomers)
> 
> * an RDF/XML profile (as above) designed for maximum compatibility
> with XPath/XSLT/XQuery
> 
> * a JSON syntax (the recent work by Jeni Tennison et al should inform this)
> 
> * GRDDL/JSON (maybe more appropriate as part of a GRDDL 1.1)
> 
> Just to reiterate, these are all incremental-addition kind of things,
> suggesting RDF Second Edition (or v 1.2), no namespace changes
> required.
> 
> Though not actually part of the RDF spec effort itself, it would be
> good to see a mapping for *every single* W3C format to RDF/XML (with
> GRDDL coverage).
> 
> Cheers,
> Danny.
> 
> 
> 
> 
> 
> 
>

Received on Thursday, 14 January 2010 10:52:37 UTC