[foaf-protocols] EAV

Kingsley Idehen kidehen at openlinksw.com
Thu Dec 16 22:19:22 CET 2010


On 12/16/10 3:55 PM, Nathan wrote:
> Kingsley Idehen wrote:
>>> When we agree, that there needs to be some canonical syntax, question
>>> rises: which? It can be any RDF serialization, OData, or some other EAV
>>> based syntax.
>>
>> Just a EAV graph. When you pull back the encoding of most structured 
>> data in the wild today (and from the past) you will find EAV at the 
>> base, and spin to the side its basically FOL logic.
>
> Kingsley,
>
> I have to ask, is that correct? I still can't see how RDF is EAV at 
> the base, I can see how it could be stored in the same model as EAV 
> data, from a DBMS perspective, and also how the foreign key attributes 
> relate to webized properties/predicates, but surely RDF is more than 
> just EAV and doesn't have everything in common with eav, open schema, 
> object property value, frame slot value, or any any of the similar 
> data models.
Subject-Predicate-Object == Entity-Attribute-Value.

You make a 3-tuple record in a DBMS (relational, property graph, 
document etc..).
>
> For one, RDF is webized, with URIs, and URIs bring many features to 
> the world of RDF not present in EAV, secondly it's got that FOL 
> description/statement aspect to it coupled with open world semantics, 
> and a labelled digraph rather than EAV "rows", for instance each node 
> can be one of those foreign keys (but they're really web-named logical 
> constants).

URIs != Webized.

URIs == Multiple Scheme based Identifiers (by way of abstraction)

Resolvable URIs may or may not be HTTP scheme based, but HTTP is very 
cost-effective due to its Web induced ubiquity (even though its own 
"deceptive simplicity" made Internet and Hypertext binding happen via HTML).

Re. EAV "Rows" here is simple experiment:

1. Open up and spreadsheet
2. Establish that you are only going to create 3-tuple records
3. In S-P (or E-A) slots give the cells Names and optionally in O (or 
Value) slot.
4. point to your Names elsewhere in spreadsheet or other workbooks in 
same spreadsheet instance.

You have a 3-tuple based Graph at this point with de-referencable Names. 
You even have demystification of Name vs Address issues (try dragging 
and dropping as mechanism for formula construction based on Cell Address 
as opposed to Named Cell).

Up ante:

1. Use macro to put "<" and ">" around Named Cells
2. Save As CSV
3. Upload to a DBMS that supports NTriples (e.g. Virtuoso).

At no point have you done anything unique to RDF bar #3 above using 
NTriples encoding.

What I describe above is going to materialize as a practical method for 
rapidly fixing Linked Data once comprehension dust settles. In my case, 
I used this approach to cross link SUMO, FAO, and DBpedia  data for 
countries as part of the process of trying to convince someone to 
enhance their data using DBpedia URIs without adversely affecting the 
aesthetics of his pretty HTML pages etc.. My skeptic was a 
run-of-the-mill RDF-hater :-)


Object Relational DBMS engines tried to bridge the Object DBMS vs 
Relational DBMS gulf by supporting Reference values i.e., using engine 
specific variants ODMG-QL that included constructs for referencing and 
de-referencing values of type "Reference". Thus, you de-reference an and 
get a back graph that provided faster record access and ability to 
perform real-world object modeling.

The key issue here is "Reference" values in the DBMS. Relational DBMS 
engines traditionally didn't allow this (until ORDBMS engines came on 
the scene but this was done in none standard fashsion).

To conclude, EAV + URIs is old. There's a massive audience out there 
that doesn't make this connection with RDF, just as the tiny RDF 
audience doesn't generally make this connection with the DBMS world.


>
> Ultimately I guess that I keep taking what you say about EAV to 
> suggest that these techs are in a tree, where EAV is at the top of 
> that tree, whereas I see it more like EAV is like a subset of RDF and 
> potentially compatible with RDF, and RDF is a subset of "potential 
> RDF", N3 - saying that, I do also see how for some people, relating 
> EAV to RDF would be a good approach to grokking it, but surely we 
> can't just take any EAV data and call it RDF, or take any RDF and call 
> it EAV, even just the open world semantics and the inherited features 
> of URIs are enough to often mean the RDFized data doesn't "say" what 
> was originally intended.

EAV (the data model) has never been a subset of RDF, it predates RDF. 
De-referencable Identifiers in DBMS engines (Object and Object 
Relational) also predates RDF and the Linked Data meme. What RDF 
delivers is an optional mechanism for doing for Data what HTML did for 
Documents re. hypermedia.

Links:

1. http://ontolog.cim3.net/forum/ontolog-forum/2010-10/msg00263.html -- 
my post about this during a conversation with John F. Sowa on ontolog 
forum, I give live examples as per usual :-)



Kingsley
>
> Best,
>
> Nathan
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen







More information about the foaf-protocols mailing list