ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Data & Relations

To: ontolog-forum@xxxxxxxxxxxxxxxx
From: Kingsley Idehen <kidehen@xxxxxxxxxxxxxx>
Date: Thu, 30 May 2013 07:43:00 -0400
Message-id: <51A73B44.2070900@xxxxxxxxxxxxxx>
On 5/30/13 7:04 AM, John F Sowa wrote:
> Kingsley,
>
> I like the idea.  I believe you can do it with a minimum of jargon.
>
> KI
>> to build a comparison (for moderately technical and attention challenged
>> audience) between relational tables oriented RDBMS systems and
>> relational (property/predicate) graph oriented RDBMS systems:
>>
>> 1. Relationship Representation
>> 2. Relation Representation
>> 3. Identifiers Types
>> 4. Data Value Types (aka. Datatypes)
>> 5. Entity Relationship Semantics Granularity.
> All those terms should be mentioned, but *not* at the beginning of
> a tutorial for the audience you mention.
>
> Instead, I suggest that you start with something that is much easier
> to introduce:  *spreadsheets* -- and the difference between the column
> headings of the spreadsheet and the identifiers of values in the rows.
> That gives you tables that can represent anything in any RDBMS.    (01)

Certainly! That's an approach I've recommended in the past with regards 
to basic Linked Data concepts. I use the cell and range naming feature 
of spreadsheets to demonstrate Name->Address indirection at a high level.
>
> For graphs, I do *not* recommend that you use RDF or even N3 or Turtle.
> Instead, I suggest E-R diagrams for the entity types and relations.    (02)

Sure. Actual notations for encoding machine readable structured data 
always come into play much later.    (03)

>
> Then convert E-R diagrams to *instance graphs* just by combining
> identifiers and type labels.  For example, change entity type Person
> to the *typed instance* Person:Kingsley or Person:"Kingsley Idehen".
>
> After you do that, you can show how to map the info from a table
> (spreadsheet) to and from instance graphs.    (04)

Yes.    (05)

>
> For the blank nodes in RDF (which represent existential quantifiers),
> you could write Person:∃ -- that's a bit of jargony notation, but it's
> only one easy to remember symbol.  And it's *much* easier to say that
> ∃ means "there exists something of the given type" than to explain
> what blank nodes mean in RDF.    (06)

I stay away from blank nodes for these kinds of presentations. 
Basically, blank nodes and reification serve important purposes that are 
only appreciated if comprehension is established.    (07)

>
> After you get the reader from E-R diagrams to instance diagrams
> with ∃ for blank nodes, you have full RDF.  To move to full first
> order logic, you only need one more feature:  a notation for
> negating any graph or subgraph.  Fortunately, Peirce invented that.
>
> See my intro to Common Logic for that option:
>
>      http://www.jfsowa.com/talks/clintro.pdf
>
> You could do something along the lines of slides 7 to 10, but with
> the notation of instance graphs (and shaded ovals for negation)
> instead of Peirce's original notation.
>
> For an advanced exercise (optional for the novices), you can show how
> to map an SQL WHERE-clause (which supports full FOL) to instance graphs
> with negation and blank nodes marked with ∃.  For the nodes that
> correspond to the desired answers, replace "∃" with "?"
>
> With this approach you can cover all the items on your list by
> starting with nothing more than spreadsheets and a subset of
> E-R diagrams:
>
>    1. Use the same type labels in E-R and the headings of spreadsheets.
>
>    2. Use the same strings in the boxes of the spreadsheets and
>       after the ":" in the instance graphs.
>
>    3. For query graphs, the nodes marked with "?" represent the
>       answers listed in the SELECT clause that precedes the WHERE.
>
>    4. Then show how queries in the notation of instance graphs
>       can be mapped to SQL -- or SPARQL.
>
> That gives you a tutorial with almost no jargon and a useful notation
> that the readers could begin using immediately.  In fact, you could
> implement a translator from that notation to RDF, SQL, and SPARQL
> that would eliminate the need for them to learn any other notation.    (08)

Yes, remember, we have support for SPARQL inside SQL and vice versa in 
our Virtuoso DBMS which easily showcases the power of hybrid DBMS 
technology. The end game is always about demonstrating that we are 
dealing with a "horses for courses" scenario since one size never fits 
all etc..    (09)

Thanks!    (010)

>
> John
>   
> _________________________________________________________________
> 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
>       (011)


--     (012)

Regards,    (013)

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen    (014)

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>