RE: Taking an axe RDF in XML? (no thank you)

Bill there are a whole host of points I'd like to respond to, but I think 
the key difference in our viewpoints is here:

[[[
>I don't agree this is the problem. People are not working and
>thinking in RDF and that's almost wholly down to the syntax.
]]]

If we want this technology to take off, I don't think that beating on 
everyone to "work and think" in RDF is the way.  When I suggest to people 
who are proposing to use XML for some purpose that they might use RDF, the 
response has been universally negative.  They're familiar and comfortable 
with XML, and don't want to leap into a new unknown.  Indeed, you too have 
observed this:
[[[
>Nonetheless, other wgs, specifically WS ones, don't seem all that
>interested in RDF as base material, unless things have changed in
>the last few months. It's astonishing to me that WSDL may get out
>the door and not be written in an RDFXML.
]]]

What I'm suggesting is that folks can be persuaded to make some small 
changes to their XML, to be compatible with the RDF serialization 
syntax.  My one success in getting RDF used by product developers was 
exactly this.  In this way, the front-loaded costs are practically zero, 
but the information is readily available to pioneering RDF 
developments.  As more applications come on stream, I would expect more 
developers to realize the benefits and adopt more of the RDF mindset.  It's 
a migration stretegy.  Without such a strategy, I fear that the success of 
XML which actually work against adoption of RDF.

Regarding WS, if we focused on promoting the information model and showing 
how their XML could be adapted to accommodate it within the RDF/XML 
serialization syntax, I think we'd have a chance to make more headway 
there.  As long as they use URIs for all meaningful identifiers, I think 
the rest could be pretty painless.


Other points sparked my your message:

- Here in UK, whenever public opinion goes against the politicians they 
seem to resort to complaining that the policies are fine, they are just not 
getting their message over well enough.   Now they're all obsessed with 
"spin" and politics is pretty much a content-free zone.  I expect the 
pattern is repeated elsewhere.

- The primary role of N-triples is to show how the XML maps to an RDF 
graph.  A simple format with a direct and obvious relationship to the graph 
was required.  The XML serialization isn't that, but that doesn't mean it's 
not suitable for expressing RDF at a slightly higher level.

- Ease of use.  Yes of course we want this.  But there are different 
constituencies here:  two are programmers and what I'll call information 
designers (or product designers).  My experience is that production 
programmers idea of easy to use is being able to work with their existing 
XML tools.  As far as I can tell, very many of the people doing information 
design choose to use something like Notation 3.  In the long run, I think 
it will be easier for software to adapt to the needs of information 
designers rather than vice versa.

#g
--

At 01:50 PM 5/23/02 +0100, Bill de hÓra wrote:
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
> > -----Original Message-----
> > From: Graham Klyne [mailto:GK@ninebynine.org]
> >
> > Bill,
> >
> > I think there's an implicit assumption in your message that
> > the existing
> > XML serialization of RDF is not suitable for its purpose.
>
>Graham,
>
>I don't altogether agree, but I suspect have a different notion of
>fitness for purpose.
>
>Let me clarify what I think the purpose of the XML serialization
>is. The XML serialization is there to get RDF adopted and used,
>nothing more. Behind that /is/ an assumption and it is this: in
>software tools, syntax and ease of use  count for more than
>semantics or correctness.
>
>The XML serialization is means-ended: it's a carrier, there so that
>RDF graphs and the underlying consequences of the MT can be held
>within it. Kendall Grant Clark suggests:
>
>[[[
>my theory about why RDF is not widely used is that to date it has
>not been well evangelized.
>]]]
>
>He's suggested that this is the role of the primer. I'm suggesting
>that this is the role of the XML serialization.
>
>
> > I'm not saying it's perfect, just a lot better than it's
> > sometimes given
> > credit for.  It's biggest problem (IMO) was it's original
> > documentation
> > (which is easy for me to say in hindsight...)
>
>I think it's clear enough I agree the state of current syntax draft
>is a vast improvement over the M&S.  On the other hand, the wg did
>invent ntriples to get some work done and as far as I know is still
>using it. Not eating your own dogfood is cause for concern. When I
>see the wg and the director move to the XML, no doubt I'll recant.
>
>
> > If there's a problem, I think it's that we're failing to
> > capitalize on this
> > migration path to RDF.
>
>I don't agree this is the problem. People are not working and
>thinking in RDF and that's almost wholly down to the syntax. RDF
>compatible is good, but is a poor substitute for RDF inside. It's
>also dissonant; while I'm thinking in domain X in my modelling
>language, I have to saccade to be sure about RDF upward
>compatibility. Make it easy for me to think about domain X /in/ RDF
>not /for/ RDF.
>
>
> > >4) Wrt to deployment, RDF's costs are frontloaded. We think
> > it's going
> > >useful, some day, because we have a notion that information
> > in RDF form
> > >is highly repurposable and easy to merge (serializations
> > >notwithstanding). I haven't seen much by way of acknowledgement
> > >that  RDF is a pension plan for your information, and surely it
> > wouldn’t hurt
> > >any to get this message across some more.
> >
> > #g:
> >
> > I agree strongly with almost everything you say here.  Except
> > that   intelligent use of the XML serialization means that the
> > front-loaded  costs can be practically zero as an increment on
> > using XML.  Design your XML
> > application format to be RDF compatible.  Later, when the
> > tools are widely
> > available to handle this as pure RDF data, a return on almost
> > no investment
> > can be realized.
>
>I think the costs are nowhere near zero, though they have dropped
>considerably in the last year.
>
>Nonetheless, other wgs, specifically WS ones, don't seem all that
>interested in RDF as base material, unless things have changed in
>the last few months. It's astonishing to me that WSDL may get out
>the door and not be written in an RDFXML.
>
>I've been hearing about the toolsets for a while. Danbri has
>suggested in the past the RDF dev community aren't closers of a
>sort. I challenged it then and still find it an anomaly difficult
>to credit; it's looking for answers in the wrong place. This is a
>classic bootstrapping problem; to break the cycle simplify the XML.
>
>Syntactically, things still are not user friendly enough and I put
>that down almost solely to the scope of the charter, not the
>members of the wg, nor how RDF core goes about its business.
>
>I humbly suggest that if a XML syntax is developed, a simple not a
>clever one, you'll see the tools and people modelling RDF because
>they have the tools, within six months of that syntax being
>uploaded. Clear this barrier to adoption and the only thing that
>can hold back RDF then are the innate complexity of RDF graphs or
>the innate inability of RDF developers to ship One-Oh code, neither
>of which I suggest are the barriers purported. Otherwise short of a
>killer app, RDF will remain a fringe or sleeper technology while
>the world carries on with the likes of WSDL, XMLSchema, XMI or the
>Model Driven Architecture.
>
>Bill de hÓra
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP 7.0.4
>
>iQA/AwUBPOzllOaWiFwg2CH4EQKyPgCg963nyM09Lv2f5Yq2K1Sezukt8NEAn3Jp
>oh4Nv3W8kRNLJ6ng3VcQ+LL9
>=Wgbl
>-----END PGP SIGNATURE-----

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Thursday, 23 May 2002 12:40:31 UTC