On 9/4/12 3:41 PM, doug foxvog wrote:
> On Tue, September 4, 2012 12:34, Kingsley Idehen wrote:
>> On 9/4/12 11:55 AM, doug foxvog wrote:
>>> On Sun, September 2, 2012 10:43, Kingsley Idehen wrote:
>>>> On 9/1/12 1:37 PM, John F Sowa wrote:
>>>>> Denise, Michael B, Kingsley, and Andries,
>>>>> Before commenting on the details of your notes, I'd like to emphasize
>>>>> an excerpt from the original DAML report by Tim Berners-Lee:
>>>>>> The goal of interoperability between heterogeneous components that
>>>>>> we build is one that will test the extent to which the Semantic Web
>>>>>> is achieving its promise. The more diverse the systems
>>>>>> interoperating, the greater the merit of the Semantic Web.
>>>>> The date of the proposal is February 2000:
>>>>> Finally, the Final Technical Report from September 2006:
>>>>> No legacy systems, no relational databases, and no possibility
>>>>> of interoperating with any data not represented in RDF.
>>>> You are right in some ways, but there are nuances that need to be
>>>> considered. Let's start with RDF, what is it actually?
>>>> Its about the entity-attribute-value model enhanced with explicit
>>> This is where the trouble comes in. RDF is a triples model with some
>>> semantics attached. Many things are difficult to model with triples
>>> (but not impossible).
>> Yes, there's always an issue with context formalization and semantics.
>> Basically, the 4th column in quad patterns is something that needs
>> formalization (model theory and specs). Pat Hayes and others are
>> tackling this matter, orthogonally, on the current RDF working group.
> Quads allow a pointer to be attached to a triple. That pointer can reference
> an object that is split into context and provenance (or equivalently a
> context which has specified provenance). Quads do not allow for higher
> relations -- except for ternary relations if context and provenance are
> And yes, i know that a module for provenance has recently been patched
> onto RDF.
> ... (01)
Its a bit more than provenance. There needs to be a formalized mechanism
for applying context to statements. Basically, dealing with the issue of
Right now, we use pragmas in SPARQL to invoke a specific entailment
regime. These pragmas explicitly tell our reasoner what ontology (world
view) should be applied to the SPARQL patterns from which a query
solution is derived. (03)
When Pat Hayes, Antoine Zimmerman et al., finish their work, we should
end up with a spec that allows us do away with pragmas since we would
have quad patterns that optionally enable a processor determine the role
of the 4th element in a loosely coupled way, backed up by formal model
theory. Believe me, this is an issue that's being worked on. (04)
>>> The main problem that i find with RDF is its being wedded to triples.
>> Before you get to that matter, you have the fact that its still wedded
>> to a formats so the model and its semantics are often lost.
> There are multiple formats for RDF. RDF is not wedded to any one format.
> I'm discussing semantic issues, not syntax. RDF being wedded to entity-
> object-value is a semantic issue. (05)
If you have a better solution than entity-attribute-value, plus classes
& relationships, with the possibility of a 4th element for loosely
binding context and temporality i.e., quads. Then fine. That's simply
isn't my area of interest right now, since I simply don't see it as the
problem at hand. Of course, that's just my opinion, as I speak for myself. (06)
>>>> Of late, I coined the phrase "R-D-F reflux" I used it to refer to folks
>>>> to have a gut reaction to those letters due to the ill effects of the
>>>> conflation and zealotry for which it (unfortunately) it is now
>>> The fight over the best syntax for RDF does blur the issue of whether
>>> the RDF model (triples) is really the best model to use.
>> Triples are a powerful starting point, at the very least.
> A steam engine is also a powerful starting point. However, to get
> the automotive industry off the ground, a newer paradigm was needed. (07)
You analogy doesn't work for me, but as I said, we are seeking different
> In this case, however, it is not a newer paradigm that is being proposed:
> higher-level computer languages since the 1950s have used routines
> which accepted more than two input values to return an output value.
> LISP was using n-tuples for encoding logic statements in 1958. (09)
RDBMS engines have worked with n-tuples for 40+ years. That doesn't make
them as useful today as they were in the past re. value pyramid
position. Pre web they occupied the apex, post Web they are a major
hindrance due to their extensional as opposed to intensional nature.
What we need is a compliment of intensional and extensional aspects of
relational database technology. Deductive DBMS engines came too early
i.e., we didn't have a ubiquitous Web to crystallize the limitations of
the extensional dimension etc..
>>>> Let's try to move past the mistakes of the past to a future that
>>>> beneficial to all. Let's try to veer the conversation towards the
>>>> entity-attribute-value model distinct from any RDF specificity since at
>>>> best, its just an optional route.
>>> Mistakes of the past, in this case, are at two levels: the one you are
>>> referring to -- forcing a messaging syntax on a public not involved in
>>> the intricacies of messaging -- and the one you are not --
>>> forcing semantic sentences on the web to be encoded
>>> using a entity-attribute-value model.
>> We start somewhere or we go nowhere.
> So, start with an n-tuple. (010)
As I said, the RDBMS took that route and it doesn't work for the
intensional side of things. Its okay for the extensional side of things.
We need 3-tuples (or maybe 4-tuples) to enable us make propositional
statements that also fit the "database record" paradigm. We need super
keys that resolve to descriptions etc.. We need a hybridization of the
extensional and intensional aspects of data management, access, and
> It is not so restricted as a triple invented
> decades later.
>> The entity-attribute-value model has been with us forever.
> Forever? (012)
Yes, forever. We humans have worked with this model forever. (013)
We give names to things.
We give names to the characteristics of things.
We give names to relationships between things.
We understand (at varying levels) the semantics that enable things to be
associated with one another.
We even now how to pack all of this into units of communication across a
variety of media. (014)
We just haven't replicated all of what we do instinctively in the new
digital medium delivered to us via the Web and Internet. (015)
>> It works. Doesn't solve everything in easiest
>> fashion but it works, and its widely understood, and actually used
>> (knowingly and unknowingly).
> An n-tuple works, is widely understood, and is actually used
> knowingly and unknowingly. The only difference with a triple
> is that many cases which are difficult to deal with using triples,
> are easy to deal with using n-tuples. (016)
Works were, at Web-scale? Silos don't count.
>>>> What ultimately matters is the ability to refer to entities (real world
>>>> or otherwise) using URIs
>>>> combined with the ability to craft their
>>>> digital representations via Web documents
>>>> where content format is varied
>>>> albeit constrained by the same fundamental data model.
>>> Such a "same fundamental data model" for all data on all data on
>>> the Semantic Web -- which i don't see as a requirement in the early SW
>>> documents -- should (imho) not use such a restrictive data model as
>> The model can be tweaked or built upon. The critical item is to use
>> foundation that's already in use.
> N-tuples are a foundation that's already in use.
>> RDF went of the rails by not
>> aggressively leveraging how it relates to EAV.
> I think you are discussing syntax here, not semantics.
> You earlier defined RDF as EAV plus semantics. (017)
I said EAV plus explicit Semantics. RDF has explicit semantics. (018)
>>> I would suggest that a "fundamental data model" should model the
>>> types of data:
>>> * (terms for) types/classes of things
>>> + specification of subtype/subclass to another type/class
>>> + specification of disjointness with another type/class
>>> * (terms for) instances of such types/classes
>>> * (terms for) relations among represented things
>>> + specification of arity of relations
>>> - single arity (can be binary)
>>> - variable arity
>>> + restriction on argument fillers of relation
>>> - to being an instance of given type(s)/class(es)
>>> - to being a subclass of given type(s)/class(es)
>>> - restrictions based on the type/superclass of another argument
>>> + specification of properties of relations
>>> - transitive - symmetric - reflexive - functional in
>>> arg N
>>> - antitransitive - asymmetric - irreflexive - ...
>>> + specification of relations among relations
>>> - subrelation - inverse subrelation - transitive closure - ...
>>> * (terms for) functions of represented things
>>> + specification of arity of function
>>> + restriction on argument fillers of function
>>> + specification of type/class of result of function applied to
>>> - to being an instance of given type(s)/class(es)
>>> - to being a subclass of given type(s)/class(es)
>>> - to being a instance/subclass of one of its arguments
>>> - restriction based on the type/superclass of an argument filler
>>> * provenance of data
>>> * contexts for data
>>> + define contexts
>>> + specify semantics of a context using statements based on relations
>>> * context of data
>>> + specification of the context in which data is valid
>>> Such a data model would not require a fixed syntax.
>> From my vantage point, if the RDF working group sort out Named Graphs
>> and Inference Context we are set. I am not seeing what isn't expressible
>> in triples from what you outline above.
>> At best, I see stuff that could be awkward to express in triples
> E.g., the variable arity relations. The accessibility of triples without
> their context or provenance.
> But why add a restriction (to triples) that complicates encoding and
> makes things hard to express?
> I admit that anything can be expressed in triples. It can also be expressed
> using a Turing Machine. In both cases there are efficiency issues. (019)
And I know that since I my company makes software that already deals
with triples and quads at massive scales with inference to boot. A
Hybrid DBMS isn't new to me neither are the concepts you are pushing. I
also see a different way forward that's non disruptive bearing in mind
the quest for no silos and Web-scale. (020)
>> or be awkward to grok at first blush etc..
>>> Under the covers
>>> (i.e., at what is now the XML level), messaging syntaxes should allow
>>> variable arity relations (as XML currently does). If someone wants to
>>> code a messaging syntax that requires triples
>>> for higher arity relations (and takes 20 times as much bandwidth),
>>> such a syntax should not be banned.
>> I don't see an XML or any other format level :-)
> XML is the bottom layer in the SW layer cake.
> Doesn't the SW require a common format for data transmission? (021)
Of course not. (022)
If you use HTTP and RESTful patterns you have content negotiation at
your disposal. Basically, shape shifting is actually an integral part of
the system. (023)
> A common
> format is what gave us the WWW. (024)
No, TimBL bootstrapped the WWW by deftly getting folks to coalesce
around HTML. That doesn't mean the WWW is all about HTML, its just how
it was bootstrapped. (025)
> Sure, we could have multiple formats, but transmitted semantic data not
> in a defined format could not be successfully received. (026)
I beg to differ. (027)
>>>> With the
>>>> aforementioned in place, we can then appreciate the virtues of denoting
>>>> real world entities with URIs that resolves to descriptor documents (or
>>>> data objects) via indirection.
>>> I note that this benefit does not require a model restriction to
>> See triples as a base. Applying functions to triples etc.. still means
>> you are working from a base.
> I see n-tuples as a base. The restriction of n to 3 only complicates
> matters. (028)
I disagree, profoundly. (029)
>>>> TimBL veered back to the Linked Data meme because he clearly realized
>>>> that RDF and the Semantic Web Project were veering off course.
>>>> Unfortunately, once the Linked Data meme took off, the gut reaction of
>>>> the RDF & Semantic Web crowd was to once again make a power-play
>>>> by conflating both things. Yes! They decided that it was beneficial to
>>>> conflate RDF and Linked Data,
>>> I agree that the Linked Data meme does not require the RDF model
>> I believe Data denotes Subject Observation.
>> I believe all observations are comprised of:
>> 1. a subject
>> 2. subject attributes
>> 3. subject attribute values.
> I note that 3.) is plural. (030)
Correct, my error, it should have been singular i.e. "value" . That was
just a typo. That doesn't eliminate a composite value. Key thing is that
I wasn't making a freudian slip that implies n-tuples.
> One common type of observation is that A is between B and C.
> How would you express this with a single triple? 8)# (031)
I would state that A is between B. A is Between C. Then I would define
the semantics of the 'Between' predicate .
>> Then to the above one has to deal with the mercurial matter of context.
>> In some cases #4 in a quad pattern. Then if we get really adventurous
>> there's temporality. For instance, all of these observations and their
>> contexts occurred in a specific time-frame.
> What is the problem with this? Databases commonly have sets of rows
> that fit together. (032)
An RDBMS has an audit trail tracking state of relations. The UX of an
RDMS is one thing, how it works behind the scenes mechanically is
another. What you see is not what's happening behind the scenes. (033)
>>>> even though history provides ample
>>>> evidence for the folly inherent in such thinking and execution
>>>>> It's time to rethink the goals of the SW and redefine the layer cake
>>>>> to incorporate a broader vision that is closer to original (plus the
>>>>> new ideas that have been introduced since 2000).
>>>> Linked Data is trying to achieve this goal. It isn't RDF syntax or
>>>> serialization specific. Its basically the entity-attribute-value model
>>> Which makes it RDF-model specific. It is this generic syntax
>>> restriction that is the basic problem that John is describing.
>> We have to start somewhere.
> That somewhere is n-tuples. Restricting n to 3 causes lots of problems. (034)
See my earlier comments. I simply don't agree with you. (035)
>> From my study of John's concerns, enemy #1 was putting syntax
>> ahead of semantics by placing semantics atop syntax.
>> With that visual and mental model in place, everything fell apart.
> John? (036)
>>> Accepting a requirement for the entity-attribute-value model
>>> is not agreeing with John's points.
>> I beg to differ as I see the issue of context as mercurial and not the
>> basis for dithering over the critical first step i.e., have something
>> that's built upon etc..
> We agree that we should start with something agreed upon to build on.
> I don't see it as dithering to avoid problematic restrictions on that first
>>>> enhanced with URIs and explicit semantics re. subject-predicate-object
>>>> or entity-attribute-value. When all is said and done we have:
>>>> 1. entity-attribute-value + classes and relationships model --
>>>> relationship semantics are implicit
>>> It is broken at this point. What (imho) is needed is:
>>> 0. classes - class instances - predicates - functions model (as
>>> specified above)
>> IMHO. It not broken, its suboptimal in certain circumstances. Those
>> circumstances don't carry enough weight to invalidate what's been
>> achieved. What, we take down the LOD cloud, and rebuild it with what?
> Removing the restriction on n=3 for tuples does not invalidate tuples
> in which n happens to equal 3.
> TimBL's initial position (which John Sowa refers to) is that multiple formats
> should be able to be handled on the SW. (037)
Correct, but I don't see it being consistent with what you are espousing
right here re. n-tuples as an alternative foundation to the 3-tuple or
potentially context aware 4-tuple. (038)
> Thus archaic formats such as
> RDF and OWL should still be able to be handled in a modern SW. This
> means that nothing would be required to be taken down.
> Of course, programs could translate legacy RDF & OWL into more modern
> languages without any semantic loss.
>>>> 2. ditto + URIs and explicit relationship semantics -- pitched as the
>>>> RDF model
>>>> 3. ditto + RDF Schema + OWL - additional relationship semantics.
>>>> As I am sure you know, the RDF zealotry can be so chronic that some
>>>> believe RDF and Semantics are one and the same thing :-(
>>> I agree. I note that you said above:
>>>> what is RDF actually? ... Its about the entity-attribute-value
>>>> enhanced with explicit semantics.
>>> Zealotry for RDF as you (correctly) define it is something we have to
>>> move past. Expressing semantics using this tight RDF
>>> constraint is problematic.
>> I would say its imperfect in certain situations. As I am sure John will
>> attest, everything is ultimately imperfect in some situation.
> But why go for the a problematic solution when a less problematic
> one (removing the constraint for triples) is easily available? (039)
I don't understand how you define easy. If what you espouse was so easy
wouldn't it exist right now and be adopted en masse? (040)
>> In the context above, 'It' refers to the entity-attribute-value model
>> combined with de-referencable URIs as a mechanism for structured data
>> representation in a form that's webby or web oriented.
> The problematic part is the EAV-only model -- not its combination with
> de-referencable URIs.
>>> I'm afraid the zealotry for triples comes from the layer cake. TimBL's
>>> signature accomplishment was the WWW based on a common messaging
>>> syntax (after all, devices that don't have a common syntax can not
>>> communicate). I note that this syntax intentionally did not restrict
>>> the syntax of the files that could be transmitted over the WWW --
>>> access to masses of existing files was required.
>> I wouldn't blame TimBL for the zealotry. I put that on the W3C's table.
> Who put RDF on top of XML in the layer cake? (041)
I don't know. But I am skeptical about it being him. Put differently, I
am skeptical about the layer cake being crafted with the unfortunate
interpretation that followed. That said, I've criticized that cake, it
was always broken, however one looked at it. (042)
>> Got to separate TimBL and the W3C, they aren't one albeit associated in
>> certain contexts.
> Agreed. TimBL certainly did not initially propose the SW as being
> based on triples.
>>> Fixing a common syntax below the Semantic Web should (imho) be
>>> it should provide a syntax for accessing data, but should not limit the
>>> semantics of the files being transmitted.
>>> An XML messaging format does just this. Adding an RDF layer above the
>>> XML layer is highly restrictive, however. XML does not require a triple
>>> model. Neither do FOL or HOL languages which can be used to encode
>>> semantics that one might expect the SW to be able to transmit. Placing
>>> a restrictive funnel on an intermediate level
>>> of the layer cake seems to me to be counterproductive.
>>> One can certainly argue with the XML base to the layer cake.
>> XML should never have been in the diagram. Period. The base of the whole
>> thing should have been URIs.
>>> such a verbose syntax is only required for specifying and enveloping
>>> data sets. A more compact syntax might be useful for encoding the
>>> semantic statements. But this issue with XML is about compactness
>>> and readability. The issue with RDF is semantic.
>> Yes, but as you can see, we have to untangle the mess first,
> To me, it is clear where the tangle is: the restriction to triples.
>> then tweak/evolve etc..
> I see no problem creating a model that legacy RDF can be mapped
> into. I'd suggest a LISP-ish notation (a la KIF and Cyc) with terms
> that can be mapped to URIs through a namespace convention. (043)
Why are you talking about a notation when you claim to be talking about
> A knowledge base would, like OWL, define a set of used ontologies
> with namespace abbreviations. The knowledge base would represent
> a context and would specify properties of that context: temporal,
> provenance, legal, geospatial, corporate, etc. Statements made in
> the knowledge base would be true in that context and could have
> additional provenance and other metadata attached.
> Accessing data from such a knowledge base would yield statements
> wrapped in a "that" (isTrueInContext C (that S)). Systems that use
> S as true could ignore C at their own risk or could accept, reject, or
> modify S depending upon the properties of C. (045)
As I said earlier, Pat Hayes, Antoine Zimmermann et al., are working on
this via formalization of quads (4-tuples)  .
>> My biggest problem is that circa., 2012 we still haven't recovered from
>> 2004, re. RDF :-(
> Agreed. "RDF ... [is] about the entity-attribute-value model enhanced
> with explicit semantics." -- KI
> We need to get beyond that.
Nice one. (046)
1. http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs -- a portal for looking
up some of the work taking place re. Quads . (049)
> -- doug foxvog
>>> -- doug
>>>> 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
>> 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
> 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
Founder & CEO
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 (053)
Description: S/MIME Cryptographic Signature
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
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)