[
Lists Home |
Date Index |
Thread Index
]
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
|
