ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Accommodating legacy software

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "doug foxvog" <doug@xxxxxxxxxx>
Date: Tue, 4 Sep 2012 11:55:42 -0400
Message-id: <77dfdc57af850d918ad651b761022681.squirrel@xxxxxxxxxxxxxxxxx>
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:
>>
>> TB-L
>>> 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:
>> http://www.w3.org/2000/01/sw/DevelopmentProposal
>>
>> That quotation comes from Section E on Evaluation.  Twelve years later,
>> we would expect to see interoperating systems running all the languages
>> and tools that Tim mentions (plus a lot more).  But instead of trying
>> to support maximum diversity, the SW developers narrowed their goals
>> to just RDF data with a deliberately restricted subset of logic.
>> ...
>> Following is a progress report from February 2002:
>>      http://www.w3.org/2002/02/iow2
>>...
>> Another report from November 2002:
>>      http://www.w3.org/2002/11/DAML-IOW
>> ...
>> Finally, the Final Technical Report from September 2006:
>>      http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA458366
>> ...
>> No legacy systems, no relational databases, and no possibility
>> of interoperating with any data not represented in RDF.    (01)

> John,
>
> 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
> semantics.    (02)

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).    (03)

> In addition,... its also happens to be about a collection
> of syntaxes and serialization formats.    (04)

> The problem with RDF is that its a cacophony of conflation.    (05)

This is one problem, sure.  The XML syntax is not designed to be human
readable.  It's a bloated messaging syntax.  The idea that anyone other
than coders working with messaging issues should see it, i find ridiculous.
We don't look at SOAP headers or packet headers being sent around the
internet (at least most of us don't); why should we look at XML?    (06)

The main problem that i find with RDF is its being wedded to triples.    (07)

> To make
> matters worse, zealotry has coalesced around this broken cacophony such
> that even trying to connecting with the entity-attribute-value model
> (from which its unequivocally inspired) is considered heresy.    (08)

This seems like arguing over what is the best font for displaying PASCAL,
instead of questioning whether PASCAL is really the best language to use.    (09)

> 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 associated.    (010)

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.    (011)

> 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.    (012)

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.    (013)

> What ultimately matters is the ability to refer to entities (real world
> or otherwise) using URIs    (014)

Fine.    (015)

> combined with the ability to craft their
> digital representations via Web documents    (016)

Fine.    (017)

> where content format is varied    (018)

Fine.    (019)

> albeit constrained by the same fundamental data model.    (020)

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
entity-attribute-value.    (021)

I would suggest that a "fundamental data model" should model the following
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 filler
  + 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 arguments
    - 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    (022)

Such a data model would not require a fixed syntax.  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.    (023)

> 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.    (024)

I note that this benefit does not require a model restriction to triples.    (025)

> TimBL veered back to the Linked Data meme because he clearly realized
> that RDF and the Semantic Web Project were veering off course.    (026)

> 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,    (027)

I agree that the Linked Data meme does not require the RDF model
(triples).    (028)

> even though history provides ample
> evidence for the folly inherent in such thinking and execution strategy.    (029)



>> ...    (030)

>> 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).    (031)

> Linked Data is trying to achieve this goal. It isn't RDF syntax or
> serialization specific. Its basically the entity-attribute-value model    (032)

Which makes it RDF model specific.  It is this generic syntax restriction
that is the basic problem that John is describing.  Accepting a requirement
for the entity-attribute-value model is not agreeing with John's points.    (033)

> enhanced with URIs and explicit semantics re. subject-predicate-object
> or entity-attribute-value.  When all is said and done we have:    (034)

> 1. entity-attribute-value + classes and relationships model --
> relationship semantics are implicit    (035)

It is broken at this point.  What (imho) is needed is:    (036)

0. classes - class instances - predicates - functions model (as specified
    above)    (037)

> 2. ditto + URIs and explicit relationship semantics -- pitched as the
> RDF model
> 3. ditto + RDF Schema + OWL - additional relationship semantics.    (038)

> As I am sure you know, the RDF zealotry can be so chronic that some even
> believe RDF and Semantics are one and the same thing :-(    (039)

I agree.  I note that you said above:
>     what is RDF actually? ... Its about the entity-attribute-value model
>     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.    (040)

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.    (041)

Fixing a common syntax below the Semantic Web should (imho) be similar;
it should provide a syntax for accessing data, but should not limit the
semantics of the files being transmitted.    (042)

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.    (043)

One can certainly argue with the XML base to the layer cake.  Perhaps
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.    (044)

-- doug    (045)

>> ...
>> John
> --
>
> 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    (046)


_________________________________________________________________
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    (047)

<Prev in Thread] Current Thread [Next in Thread>