[
Lists Home |
Date Index |
Thread Index
]
Scalability often requires an apriori knowledge of the schema, but you can represents triples very easily in a rowset, you know :-). There are other ways to make your relational schema extensible...
Best regards
Michael
> -----Original Message-----
> From: Didier PH Martin [mailto:martind@netfolder.com]
> Sent: Thursday, June 10, 2004 10:10 AM
> To: Michael Rys; 'Bill de hÓra'
> Cc: 'Jonathan Borden'; 'XML Developers List'
> Subject: RE: [xml-dev] Meta-somethingorother (was the semantic web mega-
> permathread thing)
>
> 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
|
