- From: Len Bullard <cbullard@hiwaay.net>
- Date: Fri, 25 Feb 2000 20:45:03 -0600
- To: David Megginson <david@megginson.com>
- CC: xml-dev@xml.org, www-rdf-interest@w3.org
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
Received on Friday, 25 February 2000 21:49:47 UTC