[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Picking the Tools
- From: Jonathan Borden <email@example.com>
- To: Uche Ogbuji <firstname.lastname@example.org>,"Bullard, Claude L (Len)" <email@example.com>
- Date: Mon, 21 May 2001 13:18:11 -0400
I suspect that you have successfully be flame baited! The suggestion that
something could actually be _more_ abstract than the combination of RDF, TM
and XML Schema ... :-))
Jonathan (appreciating the chuckle very much)
> > If one models at the level of UML, one should be able
> > to create both RDF and Topic Map instances of the UML
> > models. Yes or no?
> > Given that we have XML Schemas, Topic Maps, RDF, and
> > so forth, isn't it prudent to work with an abstract
> > modeling technology such as UML over any of the above?
> I'm probably the wrong person to ask this. Remember that I'm only an
> occasional amateur of object-oriented development, and I am quite opposed
> to its use in any modeling outside what I consider to be its strength: the
> packaging of code modules.
> One of the reasons I work so much with XML and RDF is that they are *more*
> abstract than OO, and allow OO modeling as well as other forms, all of
> which, on aggregate, are far more expressive than OO.
> Therefore I personally would be the last person to prefer UML models to
> RDF or Topic maps except for the design of code modules.
> While I'm at it, I'll note that this is also one of the reasons Python is
> my computer language of preference: it has strong OO support, in order to
> take advantage of its strengths within cohesive modules, but it is
> flexible enough that you can easily go far beyond polymorphism,
> inheritance and encapsulation when need be. C++ also gives you this
> capability, although you have to strain mightily to get it. Java simply
> denies you the opportunity of any deviation from OO orthodoxy.
> But to answer your first question, I'm sure one could almost always derive
> a mechanical conversion from XMI to RDF or XTM, and therefore UML,
> but as a general facility this will be only as good as any mechanical
> process in modeling, i.e. not very good.
> Uche Ogbuji Principal Consultant
> firstname.lastname@example.org +1 303 583 9900 x 101
> Fourthought, Inc. http://Fourthought.com
> 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
> Software-engineering, knowledge-management, XML, CORBA, Linux, Python
> The xml-dev list is sponsored by XML.org, an initiative of OASIS
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: email@example.com