xml-dev - Re: A certain difficulty

[Len Bullard <cbullard@hiwaay.net>]

David Megginson wrote:
> 
> Len Bullard <cbullard@hiwaay.net> writes:
> 
> > RDF: why?
> 
> To exchange serialized objects independent of protocols or programming
> language (forget about the semantic web hooey).  

But why not just exchange the serialized objects?  IOW, is RDF doing 
something I can't do with Java, C++, etc.?  I have this uncomfortable 
feeling RDF ends up being MID0.1:  what we were doing before they 
told us not to do an object-oriented programming language.  Oh well...

> RDF is suboptimal for
> this, but it gets a lot of things right (i.e. extensibility) and there
> doesn't seem to be another reasonable candidate out there yet.

See last question.  It seems we keep coming back through this time 
loop of development:  markup to wrap named property values, then 
more markup to define the names of the names of the property values, 
then more markup to define the relationships among the names of the 
names of the property values.  Jeez.  No wonder HTML became popular. :-)

> On the other hand, the RDF-Syntax spec is scaring people away in droves, so
> it's hard to know what to do.

Cull out the simplest subset.  Cull out the next simplest subset.  If 
that can't be done because there is no way to simplify it, consider it 
may be a problem with too big a scope, that is, incoherent.  TimBL 
speaks of an implementation.  What problems will it solve?  Given 
some framework the grunts know (eg, MS browser, Java VM, DHTML, 
and XML-capable objects), what do I do with RDF and who do I do 
it with?

> There's a lot of money in this: e-commerce requires much richer data
> nowadays, and retailers want that data to flow from wholesalers and
> wholesalers want that data to flow from producers.  If you take a look
> at data-exchange right now (tab-delimited dumps, product-specific
> tables, etc.) it's a bit of a bad joke.  

Not too bad. CSV definitely sux but we make good profit doing it. 
If I take a product specific table and provide even a simple 
schema

fieldname  fieldtype  description

most customers can work with it as long as it is relational, 
SQL compliant, and I throw in ODBC to make it possible to link 
where export/import isn't acceptable.  It works until they 
ask us for new table fields (easy to provide) but want it 
to be used in a relationship we don't want to support.  BTW, that 
is the key knock on relational systems:  easy to maintain, 
expensive to customize because of support costs.  So 
they get COTS or not and if they want custom, they pay.  Dearly.
If they accept COTS, they conform. (Before I get hung, there 
are national standards for the datasets; every state customizes 
them and if you go international, it is truly bizarre.)

> Writing specific XML formats
> for each exchange task is a small improvement, but you miss out on the
> network effect of being able to share 90% of the processing software,
> because the XML data model is too low-level.

Errrr.... weren't we supposed to get datatypes from X-schema for that? 
We just worked through X3D and the parse models nailed us.  OTOH, there 
are alternate XML solutions but it came down to a processing model.  
How is a 
data declaration language supposed to solve the problem of sharing 
processing software? 

(Dang.  It is the MID again.  My aching patootie...)

len


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************