Re: What Does Point Number 3 of TimBL's Linked Data Mean?

On 6/21/13 7:28 PM, David Booth wrote:
> On 06/21/2013 01:06 PM, Kingsley Idehen wrote:
>> All,
>>
>> Situation Analysis (for additional context):
>>
>> There are two versions of Design Issues documents [1][2] from TimBL
>> where the primary topic is Linked Data. Both documents a comprised of
>> four bullet points that outline a principled approach to document
>> content production and publication en route to a Web of Data.
>>
>> Naturally, for a majority of folks, TimBL's design issue memes
>> (irrespective of their clearly stated disclaimers) are deemed
>> authoritative with regards to matters relating to Web Architecture and
>> best practices.
>
> Again, that is a *mischaracterization*.  TimBl's design issue memes 
> are not dictums to be blindly followed.  They offer *insights* that 
> must be *understood*.  They are *brilliant* insights if they are 
> understood, but they are also terse, sloppily written, full of typos, 
> and dependent on a lot on context to understand.  Thus they are easily 
> misunderstood as well.
>
>>
>> Current Problem:
>>
>> The fundamental meaning of point three in both Linked Data memes has
>> *inadvertently* lead to very strong differences of opinion, with regards
>> to interpretation. Here are the two interpretations (that I know of)
>> which stand out the most:
>>
>> 1. RDF and SPARQL are implementation details
>> 2. RDF and SPARQL aren't implementation details -- basically, you can't
>> produce Linked Data without knowledge and/or a commitment to either.
>
> Yet again you have mischaracterized this debate.  AFAIK *nobody* on 
> this list has claimed that SPARQL is a required element of Linked 
> Data, even though it may be a *common* element.
>
> *Think* about it.  Can the goals of the Semantic Web be achieved 
> without SPARQL?  Certainly.  Can they be achieved without RDF? Not 
> without re-architecting the Semantic Web, because without a standard 
> universal data model, we would have walled gardens of data that a 
> client application could not meaningfully combine.

David,

Please look at the title of this post. Ditto my issues of concern. I 
haven't made the Semantic Web the focal point of my concerns. Who is 
doing the re-framing and mischaracterization?

If you agree with a point just say so. I've asked you a number of yes/no 
questions for which you are yet to respond (assuming I haven't missed 
such responses). If you agree with venn diagram say so. It really quite 
simple.

>
>>
>> Why do we need to resolve this matter?
>>
>> It has become a distraction at every level, it is basically leading to
>> fragmentation where there should be common understanding. For example,
>> some of us are more comfortable with RDF and SPARQL as implementation
>> details while others aren't (it seems!). This difference of
>> interpretation appears insignificant at first blush, but as you
>> drill-down into the many threads about this matter we also hit the key
>> issues of *tolerance* vs *dogma*.
>
> No, it is not about *dogma*, it is about conforming to *architecture* 
> to make the Semantic Web work.  The use of URIs in the web is not 
> dogma, it is a fundamental piece of the architecture that makes the 
> web work. 

When have I claimed or insinuated that URIs are dogma? Can you point to 
a single example of this claim? Should you want to reply this question, 
do look at the subject heading of this post first.

> Similarly, RDF is a fundamental piece of the architecture that makes 
> the Semantic Web work. 

That's where we differ. Right here!

To me "RDF" and "the Semantic Web" are literal identifiers that denote a 
concept. The concept in question is about web-like structured data that 
scales to the Internet and Web combined with machine-readable entity 
relationship semantics by way of varying degrees of predicate logic.

I don't care if people understand the concept as "RDF" or "the Semantic 
Web" since the concept they denote is distinct from its labels.

Now, if you disagree with that characterization, say so.

> The Semantic Web requires a standard universal data model, just as the 
> web requires a standard universal identification scheme. 

You always need standards, that isn't the point of concern. The point of 
concern is how you get people to coalesce around the standards. Again, I 
gave an example based on the "view source" pattern that demonstrated how 
the world coalesced around HTML --  en route to a massive Internet-scale 
mesh of web-like documents without it being rammed down their throats 
dogmatically.

The wide adoption of HTML triggered its standardization efforts 
(transition from de facto to actual standard).

> URIs were chosen as that universal identification scheme; RDF was 
> chosen as that universal data model.

In your  characterization above is what concerns me. I see it this way:

URI is an IETF standard i.e., an Internet standard.

RDF is a W3C standard.

Irrespective, they are both recommended by respective bodies. That's a 
little different from being *choosen* which comes across to me as being 
*ordained*. I don't believe in standards being expressed as mandates.

I prefer a much more flexible approach whereby the standards can be at 
the front-end or back-end of the journey to the destination. I prefer to 
have the concept understood and then use that understanding to 
demonstrate the virtues of relevant associated standards.

I believe a standard should be defensible. That defensibility comes from 
the rigor of the many (not one) minds that go into the actual standard. 
A standard should never be defended on the basis of "because X says so" 
where 'X' denotes a person or organization entity of type.
>
>>
>> What do I mean by RDF and SPARQL are Linked Data implementation details?
>
> Call them implementation details if you wish, but RDF is an 
> implementation detail just as URIs are an implementation detail. Users 
> do not need to understand them, but they *must* be there for the 
> Semantic Web and the regular web to work.

Again, when have I ever indicated to you that standards are unimportant? 
Do you have any idea how many standards we (OpenLink Software) 
implemented over the last 20+ years?

I assume it isn't news you you that we only develop products that comply 
with a relevant standard in a given product domain? And when a standard 
doesn't exist, we've happily collaborated with those producing relevant 
standards.

>
>>
>> They are W3C standards that aid the process of building Linked Data (as
>> outlined in the TimBL's revised meme). That said, it doesn't mean that
>> you cannot take other paths to Linked Data while remaining 100%
>> compliant with the essence of TimBL's original Linked Data meme.
>
> Wrong.  If you believe that the essence of TimBL's Linked Data meme is 
> to enable the Semantic Web, or if you believe that Linked Data is "the 
> Semantic Web done right", then there *is* no other path to Linked 
> Data, because the Semantic Web critically relies on the use of a 
> standard universal data model, just as the regular web critically 
> relies on the use of a standard universal identification scheme: 
> URIs.  If you represent data in a non-RDF-enabled format, then client 
> applications will not able to automatically combine that data with 
> other data.  Each kind of data will be its own walled garden, and that 
> is the *opposite* of what the Semantic Web aims to achieve.  The 
> inescapable implication is that unless the Semantic Web is 
> re-architected, RDF is *required* for Linked Data to support the 
> Semantic Web, just as URIs are *required* for the web.
>
> David
>

When I use the phrase "implementation detail", it isn't incompatible 
with the utility of standards. Guess what?  Every standard is a 
formalization of implementation details. Think about that for a second.
>
>


-- 

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