Cart
[Home] [By Thread] [By Date] [Recent Entries]
Once you move to the level of extensible property set, why do you need RDF/OWL for that? A relational DB with PIVOT, or --shock-- XML can do that just fine. Not that I want to get into a "format x is better than format y", but if tools already exist that cover the scenarios, the question becomes economical why you want to invest into a different toolset/format to do what other toolsets/formats already do with acceptable cost. Best regards Michael > -----Original Message----- > From: Didier PH Martin [mailto:martind@n...] > Sent: Thursday, June 10, 2004 6:16 AM > To: 'Bill de hÓra'; Michael Rys > Cc: 'Jonathan Borden'; 'XML Developers List' > Subject: RE: Meta-somethingorother (was the semantic web mega- > permathread thing) > > Hi Bill, > > > By the way, I don't use RDF/OWL for doing like ontology work or > > defining document formats. > > > > Me too and this is why I like prototype/instance based languages like for > instance self or ECMAScript. When a platonic approach is taken everything > is > constrained by a strict schema and this obviously restricts the > combinations > you can do when dealing with a plethora of sources. In contrast to this > approach I consider a bundled set of RDF statements (i.e. an rdf > description) like a prototype, a subjective view on a resource. From > there, > I can either manually or automatically merge the different point of views > about a resource. In other words the schema emerges from the prototypes > instead of from an instantiation of occurrences originated from a deistic > classification. > > For my own work and since ProjectX (the ancestor of the semantic web) I > tend > to consider rdf descriptions as a set of properties as we did in MCL. This > frame of mind is a lot easier to deal with than graphs (obviously a view > on > an abstract concept of property ownership) or triples. I simply see the > rdf > descriptions as a set of properties. The more I have properties about a > resource the more I complete my knowledge about this resource. Merging > property sets is a knowledge acquisition process. I have to think about > the > resource, analyze or set rules to decide what is the best point of view > (statement about a resource). > > Like in MCL, having property sets organized as arrays (only one level > under > an element) is useful and arrays are easier to merge or merging rules are > easier to define since they more easily conform to set theory operators > (as > previously demonstrated by Cod). To create hierarchies we simply need a > property to act as a link to other property sets. As we all know it's > quite > easy to create hierarchies from arrays. Having arrays in separate chunks, > helps a lot to recombine them. In hierarchies we often have to cut, > extract > subset to recombine them. This is what languages like DSSSL or XSLT do. In > the case of DSSSL the whole hierarchy is perceived a list of list or > dynamic > arrays; reducing the levels as dynamic arrays allows performing the > combinations. In other words, there is a lot of advantages form the > operational point of view when data are organized as arrays (i.e. property > sets). Matter of choice... > > Cheers > Didier PH Martin
|
