RE: To RDF or not to RDF, that is the (perennial) question

All -

Please bear with me - this is my first W3C post and I'm a public subscriber
to this thread.

I'm not familiar with Atom, although the brief pro/con analysis sparking my
reply hits home with me. Overall, I feel that communicating the practical
benefits of Semantic Web technology(s) in a way that's comprehensible to
mainstream corporate decision makers is critical. This issue is also one of
the central foci in all my SemWeb related work to date. Some examples of my
work can be found here: www.davidprovost.com.

SemWeb technology, its vendors and practitioners are still primarily
populated by highly trained, highly accomplished, highly technical
individuals. In my opinion, this is to be expected since it's pretty
complicated stuff (at least to me), the field is new and evolving rapidly,
and to a great extent, the underlying theory and research are still in the
process leaving computer labs to find practical mainstream applications (no
slight intended to existing vendors, many of whom I've spoken with.) As a
result, many of these people have extensive experience solving difficult
technical problems, but may have less experience interacting with business
practitioners, decision makers, and other non-technical people.

My interest is in the commercialization of the SemWeb. When I discuss the
field with colleagues or peers (who have only a passing interest), their
eyes often glaze over and their expressions go blank. However, there are
business people that do understand the potential and in those cases, our
conversations are usually quite engaging.

In an effort to solve the communication/adoption/commercialization problem
I've been working on developing the following: a framework for prioritizing
industry entry points and defining solutions, the place of SemWeb within
corporate IT investment portfolios, the process of shareholder value
creation (for new business ventures), market strategies, quantifying the
economic benefit of SemWeb versus alternative/substitute technologies, and
finally, a generic, plain English sales presentation.

I would welcome any thoughts or suggestions related to how advance my
thinking and ideally, locate receptive business partners (I recognize this
probably isn't the forum for that.) Finally, please read this disclosure:
I'm a "for-profit" person and like many people in this field, I'm trying to
figure out how to make a living from what I've learned about the SemWeb.
I've tried to strike a balance between communicating my views without being
self-promotional - if I've failed on this count, forgive me.

Thanks for reading this far - I hope you've found it productive and I'd be
interested in any comments or questions.

David Provost


-----Original Message-----
From: www-rdf-interest-request@w3.org
[mailto:www-rdf-interest-request@w3.org] On Behalf Of Danny Ayers
Sent: Friday, January 07, 2005 8:02 AM
To: www-rdf-interest@w3.org
Cc: antone@geckotribe.com
Subject: Fwd: To RDF or not to RDF, that is the (perennial) question



The post below is from the atom-syntax list
(http://www.imc.org/atom-syntax/). I think the first couple of paragraphs
are relevant for anyone interested in SW advocacy/deployment.

---------- Forwarded message ----------
From: Antone Roundy <antone@geckotribe.com>
Date: Thu, 6 Jan 2005 10:18:10 -0700
Subject: To RDF or not to RDF, that is the (perennial) question
To: atom-syntax@imc.org

On Thursday, January 6, 2005, at 07:50  AM, Danny Ayers wrote:
> The potential benefits of RSS 1.0-like extensibility have often been 
> stated on-list. One regular counter-argument has been along the lines 
> of "I don't see what that buys us" (usually from Dare ;-), which has 
> usually prompted yet another rewording of what it does buy us.

Part of the problem is that the benefits of RDF are often explained in
language that, while I assume it's clear to people conversant with RDF, is
only vaguely comprehensible, and that with effort, to those of us who
aren't.  From time to time I catch a glimpse of the value of RDF, but I
doubt that I've ever really seen the big picture.  I see two pages on the
wiki addressing the RDF or not question
(http://www.intertwingly.net/wiki/pie/NoToRdf and
http://www.intertwingly.net/wiki/pie/XmlAndRdf), but neither strikes me as
being a good "the big picture of RDF benefits for non-RDF speakers" page.

Another part of the problem is that some people simply don't care about the
benefits that RDF offers.  While I'm sure the benefits are more than worth
cost of RDF syntax to those who do care about those benefits, they are not
for those who don't.  Is there a way to reconcile the needs of the two
groups?

I see four possible futures:

1) Atom does not use RDF and is not defined and constrained in a way that
makes it easy to convert to RDF (including elements from other namespaces).
This would make Atom significantly less useful to those who care about RDF's
benefits.

2) Atom does not use RDF, but it is defined and constrained in ways that
make it easy to convert to RDF (including extensions).  This should be at
least minimally acceptable to pretty much everyone.

3) Atom uses RDF, adding a lot of syntactic overhead and/or variability to
its structure.  This would make Atom significantly less appealing to those
who aren't conversant with RDF and/or using RDF-aware tools.

4) Atom uses RDF, but the way documents are structured is constrained to a
subset of how RDF can be structured so that it doesn't require RDF-aware
tools to process, and the amount of overhead added by the RDF syntax is
minimal.  This should be at least minimally acceptable to pretty much
everyone.

Which of #1 and #2 are we closest to right now?  Is #2 or #4 achievable?  If
so, which is preferable?  I'd like to aim for #2, but if the overhead and
obfuscation in the eyes of non-RDF speakers of #4 is truly minimal (I
suspect that RDF speakers and non-RDF speakers would have very different
definitions of "truly minimal"), I'd have no complaints about going that
route.  Also, in either case, if working toward a particular solution
significantly increases our time to completion, that's a major strike
against it.



-- 

http://dannyayers.com

Received on Friday, 7 January 2005 16:22:44 UTC