- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Fri, 17 Dec 2004 18:31:20 +0100
- To: www-rdf-interest@w3.org
- Cc: peter.hunsberger@gmail.com
The following is extracted from a long and fragmented thread over on xml-dev, I believe initiated by Roger L. Costello. Anyhow, I read a post from Peter a couple of steps back which had me jumping up and down, pointing to The Graph... I think Peter's response here highlights quite a few places where advocates of RDF, errm, could do better. ---------- Forwarded message ---------- From: Peter Hunsberger <peter.hunsberger@gmail.com> Date: Fri, 17 Dec 2004 08:57:33 -0600 Subject: Re: [xml-dev] A Systematic Approach to using Simple XML Vocabularies to Implement Large (Complex) Systems To: Danny Ayers <danny.ayers@gmail.com> Cc: xml-dev@lists.xml.org On Fri, 17 Dec 2004 11:11:29 +0100, Danny Ayers <danny.ayers@gmail.com> wrote: > On Thu, 16 Dec 2004 21:55:00 -0600, Peter Hunsberger > <peter.hunsberger@gmail.com> wrote: > > > We're certainly aware of a very close coupling from what we have to > > and from RDF. However, RDF isn't exactly something you can explain to > > a business analyst in 10 minutes and expect them to understand. > > I don't know - "...you have a model built of resources (which > correspond to things) and relationships between those resources..." I don't know if it's the semantics or what, but for some reason RDF just comes across as too geeky for the business side of the house. Maybe it's just that they've been hearing OO for 10 years and believe that "Objects" are supposed to be something good so they instantly adopt them. (Resource? What's a resource?). > > > <addess> > > <addr1 type="String"/> > > <addr2 type="String/> > > ... > > they catch onto immeaditely. Do they need to model in XML? No, they > > have no clue they are modelling in XML Thtat's why: > > > > <collection name="Address"> > > <object name="Addr1"/> > > ... > > > > works even better. As I said previously, take the model and map it > > straight to XML, > > You say "take the model" - how was that model arrived at? I would > suggest that some kind of entity-relationship analysis is useful in > the development of the vocabulary. Given that RDF offers an > entity-relationship model that has expression(s) in XML syntax, it has > the potential to be a time-saver. At this point in the process we're talking about conceptual models from white board discussions and meetings with the end users. Still a long way from ER analysis if one has a need for that, we don't: we're not building a relational database. We've got Oracle under the covers, but the analysts are building object graphs and describing the relationships between objects at a very high level which maps directly into the main user interface they use for defining the system metadata. The overall system does data management at multiple levels, and that's part of the point I'm trying to make: in a complex system you need XML models that correspond to each of the internal models used by the system. The XML that get's exposed to the business analysts (and most of the developers for that matter) when we have to talk about XML is more concrete than RDF. > > Maybe someday RDF will do something special for us. > > A large proportion of the practical applications I've seen haven't > involved RDF doing "something special", rather something very ordinary > in a consistent, Web-friendly fashion. Exactly what we already get out of XML. Explain again why I need RDF? (That's rhetorical.) > This developer story goes something like: "The data was too irregular > for a relational DB so we put it XML. Soon after we started having > problems because our data didn't fit into a hierarchical structure > very well either..." That's the crux of the issue: flat trees don't cut it, you need graphs. Several of the most valuable discussions to me of the last three months here on the list have circled around how to do that and why. We didn't know we were building a graph management system when we started out. Having done it, I'm not sure things would have turned out any better if we had known that fact before hand and attempted to exploit existing tools for such systems. I suspect the result would have been worse: we've got a very efficient system for traversing a huge amount of metadata to assemble dynamically built user interfaces on the fly with reasonable response time (sub-second for the majority of things). We're now taking the lessons learned and removing special cases and exploiting the generalized capabilities of the system for managing metadata to manage the system itself. (The classical joke about ending up with two tables get's bandied about, but is far from the truth, you need at least 12 ;-). The main technology I see that might add value in the future is Topic Maps to help formalise the white board ad-hoc modelling I talk about above. Whether that leads further into more formal ontology modelling and then to OWL and then RDF via the back door remains to be seen, but at the moment, I suspect not. > > (On your points re. syntax not mattering etc, agreed 100%) > Which why my question about why we need RDF is rhetorical :-) -- Peter Hunsberger -- http://dannyayers.com
Received on Friday, 17 December 2004 17:31:22 UTC