Re: [ontolog-forum] Southampton Uni on Linked Data (The Register)

[Adrian Walker <adriandwalker@xxxxxxxxx>]

Hi Kingsley --

You wrote that the following is the key GOLDEN idea:

1. Data Object IDs (Name oriented Refs) using URIs
2. Data Object Representation Addresses in the form of URLs
3. Data Object IDs are constructed in such a what that they resolve to
Object Representation Addresses -- an HTTP aware data server handles the
heuristics for this purpose specific Data Object Name Resolution i.e.,
dataDNS for all intents and purposes .

Could you expand a bit please?  A concrete, non-RDF example would help.

                        Thanks,  -- Adrian

Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English Q/A over SQL and RDF
Online at www.reengineeringllc.com    
Shared use is free, and there are no advertisements

Adrian Walker
Reengineering

On Tue, Mar 22, 2011 at 12:22 PM, Kingsley Idehen <kidehen@xxxxxxxxxxxxxx> wrote:

On 3/22/11 11:41 AM, John F. Sowa wrote:
> On 3/22/2011 7:30 AM, Ian Bailey wrote:
>> Interesting that The Register is looking at this. No earth-shattering
>> revelations though…
>>
>> http://www.theregister.co.uk/2011/03/22/southampton_linked_data_semantic_web/
> Thanks for the pointer.
>
> I agree that there's nothing earth-shattering in it, but the following
> comment is significant:
>

John,

>> However, finding wider enthusiasm expressed in Southampton for
>> Sir Tim Berners-Lee's relatively newborn and somewhat niche software
>> modeling system [2] remains a big challenge.
> That footnote [2] points to Sir Tim's 2006 paper on Linked Data, which
> was updated in 2009:  http://www.w3.org/DesignIssues/LinkedData.html

Some history, bearing in mind my proximity to Linked Data bootstrap via
DBpedia and LOD.

When TimBL first penned the Design Issues meme that had "Linked Data" as
its subject, RDF specificity did not exist. It was GOLDEN i.e, it
focused on the central issues of Linked Data Structures (an old concept)
at InterWeb scale.

Unfortunately, and for reasons I cannot explain to this day, "RDF and
SPARQL" crept into a later version of this meme. Thus, only if one takes
a journey back in time via Wikipedia can you see the devolution of what
was a GOLDEN meme.

I've voiced my concern and frustration repeatedly about RDF specificity
being an utter distraction and detraction re. purity of InterWeb scale
Linked Data Structures that provide an effective mechanism for "whole
data representation" via links -- using HTTP and other URI schemes.

> But that paper still pushes RDF as "the standard".  As the Register
> noted, getting people to use that "niche software" is a big challenge.
>
> They quote one advocate as saying that RDF "is simple to use; it has
> got this mystique amongst some people as being very complicated and
> difficult, but it has a very simple data model."
>
> Saying that RDF has a simple data model is like saying a Turing machine
> is simple because it maps everything to n-tuples.  But sometimes a bit
> more structure can make life a lot more pleasant.

The bigger problem is the inferred claim that RDF is the only data
format bound to a data model with grounding in first-logic which is
utter bunkum (to put things mildly). Or that Linked Data == RDF.

> As an example, I have been looking at CouchDB, which uses JSON.
> Brief summary of CouchDB:
>
>    1. A B-tree manager whose records are JSON expressions.
>
>    2. Open-source, available from Apache, with bindings to all common
>       programming languages, including _javascript_ and PHP.
>       http://couchdb.apache.org
>
>    3. An HTTP interface for queries and updates, which uses map-reduce
>       to take advantage of as many CPUs as your server may have.
>
>    4. Documented by an O'Reilly book with a draft available for free:
>       http://guide.couchdb.org/draft/index.html
>
> At the end of this note is a sample JSON _expression_ used by CouchDB.
> Any quoted string could be a URI or it could be raw data of any length.
>
> Suppose that you were a programmer working at a library, and your boss
> asked you to convert the entire library catalog to Linked Open Data
> and make it available via HTTP.
>
> If you chose Couch DB, you could
>
>    1. Read the O'Reilly book.
>
>    2. Download and install CouchDB.
>
>    3. Write a trivial program to map each record in the library catalog
>       to a JSON _expression_ very similar to the example below.
>
>    4. Write a program to download every record from the library
>       catalog, convert it to JSON, and store it in CouchDB.
>
>    5. Write a web page that tells any web master anywhere in the world
>       how to write an HTTP statement for accessing that DB.
>
> With CouchDB, you could finish that job in one week.  What could you
> do with RDF and currently available tools?
>
> Of course, there is no requirement that the strings in JSON conform
> to any particular ontology.  But that is also true of RDF.
>
> JSON makes it easy to tag URIs with types.  In the following example,
> anything on the left of a colon ":" could be a type in the ontology.
> That's more readable and more compact than RDF.  One JSON structure
> also takes one DB access -- much, much less than multiple RDF triples.
>
> John
>
> -------------------------------------------------------------------
>
> Source: http://guide.couchdb.org/draft/json.html
>
> {
>     "Subject": "I like Plankton",
>     "Author": "Rusty",
>     "PostedDate": "2006-08-15T17:30:12-04:00",
>     "Tags": [
>        "plankton",
>        "baseball",
>        "decisions"
>     ],
>     "Body": "I decided today that I don't like baseball. I like plankton."
> }
>

The problem with CouchDB and friends is that RDF cloaking of the Linked
Data meme hides what the real gem is -- i.e, InterWeb super keys that
resolve to data access addresses. Basically, this is so simple to
explain in plain english when you don't have flawed marketing choices
distorting reality. The key innovation boils down to the following:

1. Data Object IDs (Name oriented Refs) using URIs
2. Data Object Representation Addresses in the form of URLs
3. Data Object IDs are constructed in such a what that they resolve to
Object Representation Addresses -- an HTTP aware data server handles the
heuristics for this purpose specific Data Object Name Resolution i.e.,
dataDNS for all intents and purposes .

Here's where and how it all deteriorates into gobbledygook:

1. URI and URL conflation -- the fact that a URL is a subClassOf URI
doesn't mean it has no purpose when explaining functional differences in
an overall system e.g. the InterWeb as a Global Data Space where each
Object has Identity (via URI Name Ref) that's intrinsically bound to the
Address of its Representation (URL)

2. Resource conflation -- inferring in a very confusing way that
"everything is a Resource" when in reality we have an Entity/Object that
is the Referent of an Identifier that resolves to a Resource that
actually bears its Representation

3. Representation Format Conflation -- somehow deciding that RDF is the
only vehicle for constructing a 3-tuple (triples or triads) that ae
constrained by a Schema

4. Schema conflation -- the schema != syntax, the schema is conceptual
and based on first-order logic (John has explained this critical point
repeatedly).


We are simply evolving the WWW from: URIs + HTTP + HTML (information
space) to: URIs + HTTP + Structured Data based on an EAV/SPO
representation of a Graph (data space) that's constrained by first-order
logic. Data formats (Representations) are Negotiable.

Decoupling Data Access Protocol from Data Representation is the real
power of the URI and HTTP combo. Why this elegance and ingenuity has to
be compromised by a flawed RDF obsession is something I'll never understand.


Kingsley

> _________________________________________________________________
> 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
> To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>
>

--

Regards,

Kingsley Idehen
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: 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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx

_________________________________________________________________
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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)