[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Meta-somethingorother (was the semantic web mega-permathre
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@n...] > Sent: Thursday, June 10, 2004 10:10 AM > To: Michael Rys; 'Bill de hÓra' > Cc: 'Jonathan Borden'; 'XML Developers List' > Subject: RE: 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|