AW: Reflections from Dan re: reception and message of RDF

> For example: "If you're used to XML or SQL schema structures,
> the schema designer is typically (not necessarily) in a much
> more authoritative role. With RDFS we stripped a lot of power
> away from schema designers: they can't tell you what to do
> any more! There's no "a shipping order *must* have an address"
> mechanism in RDFS/OWL"...

Isn't that why we put so much effort into application profiles: In order to say, this element MUST be there, that one MUST NOT, and the third one MAY?

/Lars

  **** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. ****
  **** Please note my new internet- and email-address. ****

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
l.svensson@dnb.de


> -----Ursprüngliche Nachricht-----
> Von: public-xg-lld-request@w3.org [mailto:public-xg-lld-request@w3.org]
> Im Auftrag von Thomas Baker
> Gesendet: Dienstag, 1. März 2011 04:20
> An: public-xg-lld
> Betreff: [Spam-Wahrscheinlichkeit=99]Reflections from Dan re: reception
> and message of RDF
> 
> Dear all,
> 
> In our report, we should consider Dan's eloquent
> reflections on the reception of RDF (below).
> 
> For example: "If you're used to XML or SQL schema structures,
> the schema designer is typically (not necessarily) in a much
> more authoritative role. With RDFS we stripped a lot of power
> away from schema designers: they can't tell you what to do
> any more! There's no "a shipping order *must* have an address"
> mechanism in RDFS/OWL"...
> 
> Tom
> 
> 
> On Mon, Feb 28, 2011 at 03:13:16PM -0500, Thomas Baker wrote:
> > From:         Thomas Baker <tbaker@TBAKER.DE>
> > Subject: DanBri about the RDF "message"
> > To:           DC-ARCHITECTURE@JISCMAIL.AC.UK
> >
> > Dear all,
> >
> > I'd like to share some insightful comments from Dan Brickley
> > about what has made the Semantic Web message more difficult
> > to convey than some of us had expected.
> >
> > As the comments were made on a closed list, I have with Dan's
> > permission removed the context from the excerpts below.
> >
> > Tom
> >
> >
> > Dan was asked why it has taken since 1998 to get the world to
> > understand what can be achieved with URIs and 3-tuple data
> > representations.  Dan's reply:
> >
> >     Part of our problem, I fear is that we have collectively tended
> to
> >     approach the situation with an essentially evangelical style.
> >
> >     Time and again, this has got smart people interested and
> intrigued,
> >     and so they go try out some RDF tools.
> >
> >     Very often this is a frustrating experience. And there are good
> >     technical reasons why working with RDF (* or any other '3-tuple
> based
> >     Structured Data Representation' *) will often be frustrating. The
> >     3-tuple approach thrives in chaotic situations where data flows
> >     around, with bits missing, bits added, extensions and gaps
> everywhere.
> >     This kind of data is intrinsically rather annoying to deal with.
> There
> >     are workaround and strategies (details on request :) but that
> >     frustration is inevitably core to the experience, because it is a
> set
> >     of problems the RDF data model was designed to engage with.
> >
> >     So http://www.w3.org/DesignIssues/LinkedData.html marked a
> turning
> >     point when TimBL took FOAF's RDF linking model, improved it by
> >     demanding URIs everywhere  (rather than our earlier bNodes and
> >     seeAlsos), and inspired mass publication of RDF data. Until we
> had
> >     data, few were RDF-curious. Now we have data, we can disappoint
> more
> >     curious new people per month than ever before. Or on a good day,
> make
> >     them happy.
> >
> >     The Semantic Web project has delivered several four specific
> things to
> >     the world so far: data, tools, community and standards.
> >
> >     Because it grew from a standards organization, the tendency has
> been
> >     to focus on the standards, and what they do to improve the world
> - the
> >     3-tuple model as seen in RDF, and the specs that build on top of
> it
> >     (SPARQL, RDFS/OWL etc.).
> >
> >     Now standards are great, but they're pretty distant from solving
> >     day-to-day problems. And there are good reasons to believe that
> >     3-tuple data structures will typically be annoying to use, as
> well as
> >     useful. They only really shine when multiple parties are using
> them in
> >     complementary ways, so that data can be usefully mixed and merged
> and
> >     extended and overlaid and so forth.
> >
> >     So getting those big public, link-friendly datasets out there was
> a
> >     foundation for RDFy 3-tuple data becoming more useful than it was
> >     annoying. But it's still annoying for developers, trust me!
> Having
> >     solid standards with test cases (the RDFCore 2004 revision of
> RDF) was
> >     a good step forward, but still standards alone are not enough.
> The
> >     missing ingredients are tooling and community. Both of which we
> have,
> >     both of which we can always benefit from more/better. So
> communities
> >     like the RDF/SW interest group at W3C, like Lotico, like the LOD
> group
> >     which bridged W3C's scene with the outside world, these help new
> >     adopters make the most of the 3-tuple model. I've seen quite a
> few
> >     efforts burned by mis-applying RDF in contexts where it just
> wasn't
> >     important or useful to use it. That's natural with a newish
> >     technology. And I've seen smart developers frustrated by the lack
> of
> >     documentation, polish and guidance around our tooling. But the
> growing
> >     suite of RDF-oriented tools can't be ignored, and that's a key
> part of
> >     the technology's appeal.
> >
> >     We have data, now, and that's enough to attract people. But as
> seen in
> >     discussions around eg. data.gov.uk, many mainstream developers
> see
> >     RDF, SPARQL and 3-tuples and associated tools as a hurdle or
> barrier
> >     that stands between them and data. In a way, they're right. We
> have
> >     all these standards and tools as a means to an end (sharing
> >     information, the Web's founding slogan
> >     http://www.w3.org/Illustrations/LetsShare.ai.gif "Let's share
> what we
> >     know"). RDF is not an end in itself.
> >
> >     So imho the message should not be "we've found the best technical
> >     model for sharing data on a global scale - URI-linked 3-tuples!",
> but
> >     rather, that we have a global community committed to sharing
> data,
> >     tools, standards and their own experience and time in pursuit of
> >     solving problems through information linking. This doesn't mean
> that
> >     all tools need be opensource, nor all data public, but that there
> are
> >     common architectural principles giving coherence to all this
> data, all
> >     those tools...
> >
> >     All the time we frame this as "RDF is 'easier/better' than
> >     [wonder-technology X]" we will lose. It's not. And nor is any
> vaguer
> >     notion of "3-tuples with URI" [...].  What we have here in
> >     the Semantic Web effort that is unique is a special combination
> of
> >     data, tooling, standards and community that simply can't be found
> >     anywhere else...
> >
> > And to a follow-up question on the exactly what problems people
> > and developers have with 3-tuples, or what they would rather have
> > in their place...:
> >
> >     I think it's not so much the 'what they get back'
> (API/format/model),
> >     but the whole framework of how we structure our data.
> >
> >     If you're used to XML or SQL schema structures, the schema
> designer is
> >     typically (not necessarily) in a much more authoritative role.
> With
> >     RDFS we stripped a lot of power away from schema designers: they
> can't
> >     tell you what to do any more! There's no "a shipping order *must*
> have
> >     an address" mechanism in RDFS/OWL. For e.g., as editor of the
> FOAF
> >     vocab's RDFS I can never say anything in an imperative style in
> the
> >     schema, all I can do is define the meaning of the classes and
> >     properties in the FOAF namespace. Same for the Dublin Core team,
> for
> >     SIOC, etc. This permissiveness encourages re-use in lots of
> different
> >     ways.
> >
> >     This is simultaneously critical for scaling to the Web, but also,
> as I
> >     say, annoying to be on the receiving end of. For developers
> trained in
> >     the idea that schemas tell you what is or is not an acceptable
> >     instance, RDF is strangely passive. The only formal way of
> screwing up
> >     in RDF is contradicting yourself. Someone could publish a FOAF-
> based
> >     RDF/XML document that was simply a collection of triples using
> >     'foaf:homepage'. Even with bNodes on either side of the property.
> Or
> >     someone else might publish a bunch of <foaf:Image about="uri"
> >     dc:title="...."/> triples. The FOAF vocabulary faciliates this,
> and
> >     that is useful, but it also means that knowing the vocabulary is
> not
> >     itself enough for interop. You only get interop when a bunch of
> folk
> >     do things in roughly the same way; using the same triple
> patterns.
> >     There's a whole layer to do with characterising more specific
> triple
> >     patterns, 'idioms', that is essentially missing from our
> collective
> >     practice. There have been experiments in various directions
> towards
> >     characterising such patterns (eg. using SPARQL, see
> Schemarama...) but
> >     as a community we seem to act as if schemas are all that's
> needed.
> >
> >     As Ed Dumbill put it (http://times.usefulinc.com/#13:13 via
> >     http://danbri.org/words/page/27?sioc_type=user&sioc_id=22 )
> >
> >     "Processing RDF is therefore a matter of poking around in this
> graph.
> >     Once a program has read in some RDF, it has a ball of spaghetti
> on its
> >     hands. You may like to think of RDF in the same way as a
> hashtable
> >     data structure -- you can stick whatever you want in there, in
> whatever
> >     order you want."
> >
> >     This loose nature is the key at once to our success and to our
> >     problems. The analogy is with developers who are used to nice (if
> a
> >     little brittle/rigid) OO models are not always happy replacing
> >     everything with a chaotic hashtable. At least not unless we have
> a
> >     good set of unit tests. And what we're missing, by analogy, is
> just
> >     that. Nobody knows when they've been passed a 'good' RDF graph,
> versus
> >     one so uninformative, or expressed in such alien terminology,
> that it
> >     can't be used for the task at hand. So some of the essential
> ideas
> >     from non-RDF development just don't really make sense when using
> >     unconstrained triples. That leads to headaches, frustrations etc.
> 
> --
> Thomas Baker <tbaker@tbaker.de>
>

Received on Tuesday, 1 March 2011 11:56:51 UTC