[
Lists Home |
Date Index |
Thread Index
]
Hi Michael,
> 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.
>
Good question.
For my personal usage, I do not use OWL since it imposes an apriority
constraint. So my approach is not platonic but more phenomenological. The
other point is that several sources are providing serialized data but not
access to their DB. For instance, if I want to expand my knowledge about a
resource, let's say a document accessible with an HTTP GET, then I can
create some properties manually by observing the document. However other
sources may be potentially out there to help me gather more properties, more
knowledge. For instance, Google give me some access to their DB but through
serialized documents, other people on the web may have done that too (but
very unlikely today). Then I need a tool able to merge data coming from
these sources to be as easy to use as possible. Since most of the data is
serialized, then my solution should handle serialized formats. I found RDF
or anything similar (like MCL) to be easy to deal with. Since protégé import
native RDF and since it is easy to automate the process of transforming
Google, MSN, Teoma output into RDF then RDF became the tool to play with. IN
that particular usage it’s the minimum cost. Importing all the data into a
DB is more costly for me since I'll have to write more tools instead of
re-using what's already there. This doesn't diminish the power and
versatility of today's relational DB especially since they can produce XML
and de facto RDF serializations and de facto I can input relational outputs
into my protégé modeling tool. Its not a universal panacea but it works for
certain usages.
Overall, several strategies are available to integrate diverse sources of
data, among them to reduce all of them to a single format. I am using RDF
but more and more using a variation of it I called PDML where links are
explicitly specified. I am using xlink extended inheritance to express a
collection of associations with other resources.
These are all experiments Micheal and do not pretend actually that it’s the
best solution or a universal panacea. Only that packaging property sets in
something like RDF is useful. However I would have used - as a matter of
personal choice- xlink extended inheritance to create associations with
other property sets.
So instead of
<rdf:description about="uri">
....
<associatedTo rdf:resource="uri"/>
....
</rdf:description>
I would have used
<rdf:description about="uri" xlink:type="extended"....>
<associatedTo xlink:type="locator" xlink:href="uri" ...../>
</rdf:description>
Inheriting from a link I can now navigate the structure between property
sets in a generic way. I could also include aother kind of data organization
(if they all use xlink) and then create a map of what is associated to. But
since W3C is a bit schizoid.... Anyway....
Now, more specifically about your comment. The problem with DB is that they
are driven by the schema (correct me if I am wrong, I may need to update my
knowledge with the recent releases). So if I want to dynamically change a
property set (i.e. a row) I need to change the entire collection (i.e. the
table). Thus the schema should reflect the summation of all the schemas I am
merging or I need to create different table to be merged later on. IN other
words, RDB are not prototype based but closer to a class based system (sort
of) where the schema act as a class definition and the rows as instances.
However, I should emphasizes that a major advantage of RDB compared to,
let's say, object DB is that I can compose a new object by extracting
properties from existing ones and recombining them into a new order. ON the
other hand, important data without knowing their schema or previously
creating a schema is harder to do (in any DB anyway). The frame process
supported by RDF make it easier (but not with OWL though). So RDF without
OWL is probably better adapted to prototypes or property sets published and
serialized without a constraining schema.
Cheers
Didier PH Martin
|
