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:
>>>
>>> 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.
>> 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.
> 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). (01)
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. (02)
>
>> In addition,... its also happens to be about a collection
>> of syntaxes and serialization formats.
>> The problem with RDF is that its a cacophony of conflation.
> This is one problem, sure. The XML syntax is not designed to be human
> readable. (03)
Yes, it wasn't. (04)
> It's a bloated messaging syntax. The idea that anyone other
> than coders working with messaging issues should see it, i find ridiculous. (05)
Amen! (06)
> 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?
>
> The main problem that i find with RDF is its being wedded to triples. (07)
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. (08)
>
>> 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.
> 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)
Maybe. I see it as akin to arguing about the best syntax for a model
theory. Basically, detrimental syntax and semantics conflation. (010)
>
>> 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.
> 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)
Triples are a powerful starting point, at the very least.
>
>> 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. (012)
We start somewhere or we go nowhere. The entity-attribute-value model
has been with us forever. It works. Doesn't solve everything in easiest
fashion but it works, and its widely understood, and actually used
(knowingly and unknowingly).
>
>> What ultimately matters is the ability to refer to entities (real world
>> or otherwise) using URIs
> Fine.
>
>> combined with the ability to craft their
>> digital representations via Web documents
> Fine.
>
>> where content format is varied
> Fine.
>
>> 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
> entity-attribute-value. (013)
The model can be tweaked or built upon. The critical item is to use
foundation that's already in use. RDF went of the rails by not
aggressively leveraging how it relates to EAV.
>
> 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
>
> Such a data model would not require a fixed syntax. (014)
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 or be awkward to grok at first blush etc.. (015)
> 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. (016)
I don't see an XML or any other format level :-)
>
>> 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 triples. (017)
See triples as a base. Applying functions to triples etc.. still means
you are working from a base.
>
>> 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
> (triples). (018)
I believe Data denotes Subject Observation. (019)
I believe all observations are comprised of: (020)
1. a subject
2. subject attributes
3. subject attribute values. (021)
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. (022)
>
>> even though history provides ample
>> evidence for the folly inherent in such thinking and execution strategy.
>
>
>>> ...
>>> 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. (023)
We have to start somewhere. 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. (024)
> Accepting a requirement
> for the entity-attribute-value model is not agreeing with John's points. (025)
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.. (026)
>
>> 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) (027)
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? (028)
>
>> 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 even
>> 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 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. (029)
I would say its imperfect in certain situations. As I am sure John will
attest, everything is ultimately imperfect in some situation. (030)
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.
>
> 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. (031)
I wouldn't blame TimBL for the zealotry. I put that on the W3C's table.
Got to separate TimBL and the W3C, they aren't one albeit associated in
certain contexts. (032)
>
> 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. (033)
Sorta. (034)
>
> 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. (035)
XML should never have been in the diagram. Period. The base of the whole
thing should have been URIs. (036)
> 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. (037)
Yes, but as you can see, we have to untangle the mess first, then
tweak/evolve etc.. (038)
My biggest problem is that circa., 2012 we still haven't recovered from
2004, re. RDF :-( (039)
Kingsley
>
> -- doug
>
>>> ...
>>> 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
>
> _________________________________________________________________
> 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
>
>
> (040)
-- (041)
Regards, (042)
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 (043)
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)
|