[
Lists Home |
Date Index |
Thread Index
]
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@netfolder.com]
> Sent: Thursday, June 10, 2004 6:16 AM
> To: 'Bill de hÓra'; Michael Rys
> Cc: 'Jonathan Borden'; 'XML Developers List'
> Subject: RE: [xml-dev] 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
|
