ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] RDF vs. EAR

To: ontolog-forum@xxxxxxxxxxxxxxxx
From: Kingsley Idehen <kidehen@xxxxxxxxxxxxxx>
Date: Mon, 05 Dec 2011 12:28:27 -0500
Message-id: <4EDCFF3B.2070508@xxxxxxxxxxxxxx>
On 12/5/11 12:10 PM, Ed Barkmeyer wrote:
At the other end of this, I would observe that the "geneology" of EAR 
languages is tightly tied up with relational database modeling, and most 
EAR languages are designed and written to be rendered by a rote process 
into SQL schemas.  That is, the distinction between an attribute and a 
relationship is between dependent column and table.  So the same problem 
that arises with RDF, i.e., the accumulation of associated 
implementation paradigms, is also a problem with "EAR languages".

As Pat says, from a purely formal and abstract point-of-view, EAR has 
nothing to do with relational databases, just as RDF has nothing to do 
with RDF/XML.  That journeyman software and knowledge engineers cannot 
separate concept, language, and implementation is a "people problem", 
and RDF and EAR are merely victims of it.

That said, many of us who have dealt with information modeling for these 
many long years have come to realize that the notion of a "path through 
the semantic network" is a critical idea in understanding relationships 
among information elements, particularly among competing viewpoints.  In 
RDF this is a well-understood concept -- a trace through the graph.  EAR 
does not of itself have such a notion.  Thinking of the 'path through 
the network' as a set of relational joins is representing the conceptual 
path by a particular implementation technique that can mimic it -- their 
formal models are almost unrelated.  So, I personally think of "path 
conceptualization" as a critical difference between the two models.

Yes, and this is why genealogy matters re., technology narratives. People learn a lot when they have some kind of starting foundation.


-Ed

P.S. I am a long-standing foe of the conflation of identification and 
location in URIs. 

+1000

 RDF URIs are identifiers.  How they relate to access 
to the thing identified should be an entirely separate question.

Yes!

Linked Data is very specific about the expected behavior of identifiers. It mandates that:

1. they are de-referencable
2. the resolve to descriptor documents -- format negotiable.

Trouble is RDF supporters come along and alter the above to read:

1. they are de-referencable
2. they resolve to descriptor documents -- that MUST be based on standards such as RDF, SPARQL.

It's this can of activity and refusal to fix when proven wrong that repels people from RDF (IMHO).

  In 
particular, there is a big difference between treating a URI as a 
pointer to a specific collection of information about a thing (LOD), and 
using it as an identifier that enables the collation of many sources of 
information about the thing. 

Yes.

 It is the difference between 
object-oriented pointers and relational joins.  rdf:about is one of the 
best technical ideas for knowledge sharing that was ever invented.

Yes, but it isn't syntax specific. That's where RDF gets into trouble.


Related:

1.  http://queue.acm.org/detail.cfm?id=1961297 -- A co-Relational Model of Data for Large Shared Data Banks - ACM Queue





-- 

Regards,

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




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>