Dear Ed, (01)
Could you please give some example languages which
you would consider "EAR languages" in your message
below? (02)
Thanks,
-Rich (03)
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2 (04)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On
Behalf Of Ed Barkmeyer
Sent: Monday, December 05, 2011 9:10 AM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] RDF vs. EAR (was:
NPL2RDF) (05)
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". (06)
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. (07)
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. (08)
-Ed (09)
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. (010)
--
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 (011)
"The opinions expressed above do not reflect
consensus of NIST,
and have not been reviewed by any Government
authority." (012)
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%93attrib
ute%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/abou
t
>>> 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-f
orum/
>>> 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?WikiHomePa
ge#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
>>
>>
>>
>>
>>
>>
>>
>
>
> (013)
__________________________________________________
_______________
Message Archives:
http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr:
http://ontolog.cim3.net/mailman/listinfo/ontolog-f
orum/
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?WikiHomePa
ge#nid1J (014)
_________________________________________________________________
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)
|