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". (01)
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. (02)
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. (03)
-Ed (04)
P.S. I am a long-standing foe of the conflation of identification and
location in URIs. RDF URIs are identifiers. How they relate to access
to the thing identified should be an entirely separate question. 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. 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. (05)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 (06)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (07)
Kingsley Idehen wrote:
> On 12/4/11 2:11 PM, Pat Hayes wrote:
>
>> On Dec 4, 2011, at 12:34 PM, Kingsley Idehen wrote:
>>
>>
>>> On 12/4/11 12:23 PM, Pat Hayes wrote:
>>>
>>>> Many in the RDF world would agree. However, RDF is quite independent of
>RDF/XML. Much of the world's RDF is written using other notations, and the RDF
>standard was written using an 'abstract' (graph) syntax precisely to allow a
>variety of surface notations. Just like ISO Common Logic, in fact.
>>>>
>>> All,
>>>
>>> I think we continue to miss a fundamental issue that is the root of so much
>confusion. Personally, I believe positioning RDF as both a data model and a
>collection of syntaxes is the root of the problem.
>>>
>> And what do you see "the problem" as being, exactly? Seems to me that RDF
>has (a whole host of tedious small problems, but) no really big, central
>problem.
>>
>> Still I agree that there is a muddle in the RDF world having to do with how
>best to "layer" more expressive notations (such as OWL) onto RDF. This was
>clear (and gave rise to much heated discussion) when the RDF and OWL specs
>were being written, before 2004. I think we have all learned to live with the
>awkwardnesses that it caused, however. Certainly none of the extremely dire
>consequences that were predicted have come to pass. OWL and RDF do get used
>together, and applications do actually work. OWL2 and RIF have been published
>and both layered onto RDF syntax, although admittedly in both cases
>alternative notations are more elegant and will likely get used in dedicated
>applications.
>>
>>
>>> A very simple question. How is RDF (the model) different from the long
>established Entity-Attribute-Value model?
>>>
>> Very abstractly and formally, perhaps not very different. In practice,
>however, and in intention and design, very different. Chiefly, RDF allows (and
>is mostly comprised by) data in which the 'value' is itself also an 'entity',
>so that one finds 'chains' or even (!!) graphs of links, which can get quite
>dense. This is not even contemplated in most EVA approaches. Second, the RDF
>identifiers are URIs (IRIs), as you know, which are globally unique and are
>links that can be followed using HTTP. This is hugely important and alone is
>enough to make RDF/OWL quite different in design from previous data models.
>And third, at least according to Wikipedia, EVA assumes that the entities are
>sparse in the overall attribute space, which is not part of the RDF design or
>assumptions.
>>
>
> Pat,
>
> Thanks for the reply, as I hoped, the discussion if veering towards the
> heart of what I believe the problem is. To answer your question to me, I
> believe the problem re. RDF model lies in lack of genealogy in its
> narrative, compounded by the conflation with RDF/XML syntax in its very
> early days.
>
> When I discuss Linked Data, especially at InterWeb scales, I try to
> outline the following re. the underlying graph based models that make
> the aforementioned feasible:
>
> 1. EAV -- basic model thats familiar to many developers working with
> ASN.1, XML, and most recently JSON based syntaxes
> 2. EAV + URIs -- this is what RDF as a model adds to the mix, it is
> unambiguous about the use of URIs but remains ambiguous about
> de-referencable URIs
> 3. EAV + de-referencable URIs -- this is what Linked Data mandates
> explicitly, since it is very explicit about de-reference and address-of
> operation aspects of URIs i.e, a Name is distinct from an Address even
> though URIs are used to denote either.
>
> Linked Data is still fundamentally about high fidelity structured data
> at InterWeb scale, more than anything else.
>
> RDF gets into trouble when its supporters infer that RDF is the only
> route to Linked Data at InterWeb scale. You know this is a slippery
> slope, and I even know you've tried to curb this tendency. Basically,
> RDF can be used to construct graphs that deliver InterWeb scale Linked
> Data, but that isn't something you would clearly discern from RDF specs
> due to ambiguity that remains about URI de-reference and disambiguation
> of names and address denoted by URIs.
>
> When people "gut react" to the letters R-D-F, I tend to orient the
> conversation to what's outlined above, and it works most of the time
> because I can always identity:
>
> 1. the 3-tuple pattern
> 2. the use or potential incorporation of URIs -- albeit rarely since the
> name / address ambiguity issue lingers persistently.
>
> To conclude, there is also another major RDF unique selling/value point
> that is often lost in the R-D-F arguments, and this it the issue of
> typed literals fidelity, language tags, and i18n in general. Trouble is,
> only when people get going with EAV + URIs (whether they call it RDF of
> not) will the real power come to the fore.
>
> Anyway, I think we are making progress :-)
>
> Kingsley
>
>> Pat
>>
>>
>>
>>> What does it bring to the table that differentiates it?
>>>
>>> I have some answers to the above, but I would like to see if responses to
>what's posed above (from others) could lead to clarity that's desperately
>needed re. RDF.
>>>
>>>
>>> Links:
>>>
>>> 1.
>http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model -
>EAV model
>>> 2. http://ycmi.med.yale.edu/nadkarni/eav_cr_frame.htm -- EAV/CR .
>>>
>>> --
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _________________________________________________________________
>>> 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
>>>
>> ------------------------------------------------------------
>> IHMC (850)434 8903 or (650)494 3973
>> 40 South Alcaniz St. (850)202 4416 office
>> Pensacola (850)202 4440 fax
>> FL 32502 (850)291 0667 mobile
>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>>
>>
>
>
> (08)
_________________________________________________________________
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 (09)
|