ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] knowledge base and DBs

To: ontolog-forum@xxxxxxxxxxxxxxxx
From: Kingsley Idehen <kidehen@xxxxxxxxxxxxxx>
Date: Tue, 06 Jan 2015 21:15:19 -0500
Message-id: <54AC96B7.60805@xxxxxxxxxxxxxx>
On 1/6/15 4:28 PM, Matthew West wrote:
> Dear Kingsley,
>
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
> [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Kingsley Idehen
> Sent: 06 January 2015 20:00
> To: ontolog-forum@xxxxxxxxxxxxxxxx
> Subject: Re: [ontolog-forum] knowledge base and DBs
>
> On 1/6/15 2:00 PM, Matthew West wrote:
>> Dear David and Alexander,
>> Hmmm. Well to my mind the biggest difference is not to do with
>> operations and logic, SQL is very competent. The key difference is
>> that a database has a structure that is defined at database definition
>> time, and data that is added at runtime. On the other hand, a
>> knowledge base has minimal structure, and is defined by the type of
>> knowledge base used. None of this has much to do with what you can do
>> with the different approaches, and a lot of things you can do with
>> either. A database is likely to be more efficient when there are a lot
>> of records with the same structure to be stored and referred to. A
>> knowledgebase is likely to be more efficient when flexibility in structure
> is what is required.
>> Regards
>>
>> Matthew West
>> Information  Junction
>> Mobile: +44 750 3385279
>> Skype: dr.matthew.west
>> matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
>> http://www.informationjunction.co.uk/
>> https://www.matthew-west.org.uk/
>> This email originates from Information Junction Ltd. Registered in
>> England and Wales No. 6632177.
>> Registered office: 8 Ennismore Close, Letchworth Garden City,
>> Hertfordshire,
>> SG6 2SU.
> Matthew,
>
> How about the following, which distinguishes:
>
> 1. Application that provides management services 2. Document comprised of
> content (data).
> MW: Well I would not call a database a document. It is the database that
> contains the content, and the DBMS which provides access and management
> services to the data in the database.    (01)

My very point is that a Database is a kind of Document that's quite 
distinct from an Application that provides a variety of interaction 
oriented services against the document (which is comprised of content, 
created using some notation) [1].    (02)

>
> Thus, we end up with A DBMS (Database Management System) being an
> application that provides Data Management (import, indexing, querying,
> export etc..) services (driven by its supported model) scoped to
> Document(s) [which may be internal or external] comprised of structured data
> -- represented using a variety of notations.
> [MW>] Well yes, but I still don't like calling a database a document.    (03)

It isn't a case of liking or disliking, its about actual facts, that 
have unfortunately been distorted over the years. A Database is a kind 
of Document. A Database Management System is an Application.    (04)

> A
> document suggests a lack of structure, as in a text tract, whereas a
> database is highly structured.    (05)

Documents are inherently structured. The "unstructured document" meme is 
a misnomer crafted and pushed by SQL RDBMS vendors.    (06)

>
> Which also implies that a Knowledge Management system  just another kind
> application with additional capabilities e.g., reasoning and inference.
> [MW>] A DBMS has those capabilities as well, certainly a SQL one.    (07)

Not to the degree required for anything close to achieving reasoning and 
inference that's close to real-world observations. This is also why 
they  are quite poor at integrating data from heterogeneous data sources 
[2][3].    (08)

> In both cases, if relational in orientation, these applications group tuples
> as Relational Tables and/or Relational Predicate/Property Graphs.
> [MW>] Well strictly relational tables are a different view of data from a
> graph view, though they are isomorphic. Of course you can trivially create a
> triple store using a relational database.    (09)

No, you can't do that trivially. Virtuoso (our product) is a hybrid 
DBMS, and I can assure you it would have been impossible (from a 
convention pure SQL RDBMS perspective) to get it to the point where it 
could host something like DBpedia [4] and the LOD Cloud cache [5] 
without running a zillion times slower than a snail (relatively speaking).    (010)

> Some of the differences in
> performance can arise from whether the underlying structure is graphical or
> relational.    (011)

There are many layers, you even need to touch the physical layer where 
data is stored column-wise as opposed to row-wise, amongst a host of 
other things .    (012)

Links:    (013)

[1] http://www.openlinksw.com/c/9CH6K3GF -- Document that describes a 
Database
[2] 
http://kidehen.blogspot.com/2014/12/deceptively-simple-conceptual-data.html 
-- Data Virtualization over Disparate Data Sources
[3] 
http://kidehen.blogspot.com/2014/08/linked-local-data-lld-and-linked-open.html 
-- Linked Local Data vs Linked Open Data
[4] http://kidehen.blogspot.com/2014/07/nanotation.html -- Nanotation 
(simple example of what you simply can't achieve using a SQL RDBMS)
[5] 
http://kidehen.blogspot.com/2014/02/class-equivalence-based-reasoning.html 
-- ditto .    (014)


Kingsley
>
> Regards
>
> Matthew West
> Information  Junction
> Mobile: +44 750 3385279
> Skype: dr.matthew.west
> matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
> http://www.informationjunction.co.uk/
> https://www.matthew-west.org.uk/
> This email originates from Information Junction Ltd. Registered in England
> and Wales No. 6632177.
> Registered office: 8 Ennismore Close, Letchworth Garden City, Hertfordshire,
> SG6 2SU.
>
>
> --
> Regards,
>
> Kingsley Idehen       
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2:
> http://www.openlinksw.com/blog/~kidehen
> Twitter Profile: https://twitter.com/kidehen
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
>
>
>
>   
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>   
>    (015)


-- 
Regards,    (016)

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this    (017)

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (01)

<Prev in Thread] Current Thread [Next in Thread>