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

[Kingsley Idehen <kidehen@xxxxxxxxxxxxxx>]

On 3/22/11 6:45 PM, Jans Aasman wrote:

On 3/22/11 4:33 PM, Jans Aasman wrote:

Kingsley: when you say Object, do you then actually mean a subject (of a triple) and all the triples for that subject?

No, and therein lies the problem. By trying to veer away from "Object" due to it use in SPO triples, we've ended up dislocating what "Objects" are/were outside SemWeb land.

I totally agree, but how is a person used to objects in say Java or C++ or someone using a OODBMS or object relational mapping going to understand the following?

Tell them:

The data member is decoupled from the language specific object.

I believe grasping this concept is actually quite trivial for the programmer profile you describe. The path taken via conventional RDF advocacy simply confuses everyone (experienced and inexperienced).

A Data Object has Identity via an Identifier that functions as Name.

    does that mean that a single URI/URL/URN can be an object? Or which one of those?

A URI can serve as an Object ID (functioning as a Name). An aspect of an Object that enables one to Reference it by Name.

A URL (a URI subClass that delivers actual data access as pointers do) provides the conduit to the Object's representation (an EAV/SPO graph pictorial).

Linked Data mandates Naming that enables the publisher of Linked Data to inextricably bing the Object ID (Name) with Address (URL) from which its Representation is retrieved (e.g. HTTP GET).

A Data Object has Representation.

    does that mean that it has multiple attributes and links to other objects?

Naturally.
Links are used to make the Object Representation i.e., description graph. The URI abstraction itself, enables this innovative indirection (Name to Address) to play out.

You access the Object's Representation by de-referencing its ID (Name).

   so it lives somewhere on the web...?

Data Objects exist on a Network. It so happens that HTTP ubiquity (courtesy of WWW) lowers the cost of achieving this manner of data access by reference. You can work this way on public or private networks. Sadly, this powerful reality is typically lost in the general rhetoric around Linked Data.

   your points later in this email make clear what you mean but by itself these statements above are too isolated.

Linked Data (as per TimBL's meme) extends this concept to the Network Computer we know as the Internet.

I guess you do but what I see then is that a lot of people get confused by the fact that triples themselve have an object (in RDF parlance).

Yes, the point I made above..

So I'm now talking internally about frames as the collection of triples that all have the same subject. Undoubtedly that will create new kinds of confusion but so far I like it. Jans

Yes, but it one steps out of the SemWeb box, what do you find? The same Object Graphs that OODBMS, ORDBMS, CORBA etc.. are about. The only difference re. the aforementioned is that the Objects where land-locked in a Programming Language that was typically locked into a host OS.

agreed again...

An the core of TimBL's contributions (IMHO) is an ingenious unpacking of Data Objects from artificial encapsulation at the following levels:

1. Operating System
2. Programming Language
3. Database Engine
4. Anything else that manages and inadvertently hugs data objects.

HTTP separates all the critical points of control:

1. Object Identifiers
2. Object Representation
3. Data Access Protocol.

Thus, we can now truly write data to an Address using one App. (increasingly thin code layer) and read the same data from the same Address using another App. All because the Data Object and its Representation are now 100% untethered, bar recent desires to confine this phenomenon to RDF :-)

what was wrong with RDF again? :-)

Nothing is wrong with RDF bar its narrative and positioning at the front door re. Network aware Linked Data Structures and Distributed Data Objects.

RDF has its virtues, we just don't need to ram them down peoples throats as part of the introduction to Linked Data. IMHO we build bridges by letting everyone understand this is a contemporary slant on an old concept. Eventually, people will appreciate RDF benefits that address specific needs e.g. typed literals and the ability to leverage XSLT for transformations between different data formats etc..


At OpenLink we've worked with RDF for many years, made 70+ transformers and another 70+ lookup services, and as you know even made a massively scalable DBMS that can ingest and index RDF data sources. In a nutshell, RDF only give us nothing but advantages, but none of that would make me ever consider mandating RDF to anyone as a prerequisite for Linked Data creation, deployment, and exploitation :-)


Kingsley

Kingsley 

On 3/22/2011 12:26 PM, Kingsley Idehen wrote:

On 3/22/11 1:51 PM, Adrian Walker wrote:

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.

Your computer, where each Data Object has a Data Access Address. Various Programming Langs. where abstraction delivers Objects that have Identity that provide indirection to actual Memory Addresses from which data is retrieved in a variety of representations albeit confined to each language etc...

All Linked Data does, is embrace and accentuate the "Network is the Computer" reality (old Sun Microsystems mantra) by applying the same concept to the New Computer (the Internet). Basically, the WWW is making strong claims towards becoming the definitive or predominant OS of the Internet :-)

We're are just dealing with new level of abstraction  within a new landscape for data access by reference. The core concepts are older than all of us.

Kingsley

                        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
 

-- 

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
 

-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 

-- 

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    (01)