Re: Modularization - Was[Re: LDP interfaces in Java (based on Jena and JAX-RS)]

On 8/6/12 4:51 PM, Reza B'Far (Oracle) wrote:
> Sounds good.  Seems like Erik, you (Idehen), Ashok, and I have some 
> rough agreement on what may be needed.

Yes, and I think we'll also be able to get everyone else to understand 
where we are coming from, in due course. Right now, our commonality is a 
reflection of our DBMS and Data Access Middleware backgrounds. IMHO., 
connecting our realms and the artificially disconnected realm of Linked 
Data (due to RDF conflation) is the final frontier. Pull this off and 
frustrations of the years past will vaporize etc..


Kingsley
>
> *Chairs*: do we use email as the mechanism to put forth proposals that 
> can be discussed and voted on? (for example, formalize this thread as 
> a proposal?)
>
> On 8/6/12 11:35 AM, Kingsley Idehen wrote:
>> On 8/6/12 1:15 PM, Reza B'Far (Oracle) wrote:
>>> Idehen -
>>>
>>> [Idehen]
>>> Is it accurate is I summarize all of this as boiling down to 
>>> decoupling RDF from Linked Data?
>>> [Reza]
>>> I think this is ABSOLUTELY key to me.  I confirm that, from my 
>>> perspective, this decoupling is crucial to a standardization 
>>> effort.  Doesn't mean that RDF is excluded or even that it is not a 
>>> focus, rather that it is treated separately in the standardization 
>>> process.  I mentioned this on the call this morning: Prov has done a 
>>> good job of this decoupling Prov-DM from Prov-O (OWL).
>>
>> +1
>>
>>>
>>> To this end, and your other comments, I would propose that we arrive 
>>> at a taxonomy that has, at least, the following -
>>>
>>> LDP-DM - Some Data Model that represents the domain we're trying to 
>>> address independent of any other sem-web standards (RDF, SPARQL, etc.)
>>
>> +1
>>
>> We already have the entity-attribute-value model on a platter, and 
>> broadly understood my most that have worked with DBMS technology over 
>> the last 40+ years. Thus, the worst we can do is repeat the fatal 
>> mistake of creating a complimentary DBMS technology that isn't 
>> instinctively recognized by DBMS practitioners.
>>
>>> LDP-RDF - Linkage of RDF to LDP-DM
>>> [Others]
>>>
>>> This is the model that Prov went with and I'm not saying anything 
>>> original (essentially copying from that WG).  But, I think it was 
>>> the right approach: decouple your data/domain model that represent 
>>> the necessary abstractions from the various other lower level pieces 
>>> and apparatus.
>>
>> Yes, the Web is fundamentally about the beautiful art of abstraction 
>> and loose coupling. What's TimBL delivered in his meme is how URIs 
>> ultimately address key challenges associated with:
>>
>> 1. Data Representation
>> 2. Data Access
>> 3. Data Integration.
>>
>> Note, TimBL cleverly stays clear of Data Management in appreciation 
>> of its 40+ years worth of research and history etc.. Basically, the 
>> issues above are the biggest headaches of all re. data 
>> de-silo-fication :-)
>>
>> Re points 1-3 above, I sum up Linked Data as taking us beyond open 
>> rdbms-specific connectivity to open data connectivity. Basically, we 
>> have URIs (hyperlinks) as powerful data sources names that are 
>> decoupled from data access protocol, data representation syntaxes, 
>> and data serialization formats.
>>
>> Kingsley
>>
>>>
>>> Best.
>>>
>>> On 8/6/12 8:57 AM, Kingsley Idehen wrote:
>>>> On 8/6/12 11:13 AM, Erik.Wilde@emc.com wrote:
>>>>> hello ashok.
>>>>>
>>>>> On 2012-08-06 17:03 , "Ashok Malhotra" <ashok.malhotra@oracle.com> 
>>>>> wrote:
>>>>>> I am involved in a couple of standards groups where the data is 
>>>>>> in XML or
>>>>>> JSON
>>>>>> and accessed using REST.  These folks are wrestling with he same 
>>>>>> kinds of
>>>>>> issues
>>>>>> that motivated us to the start the LDP WG:  collections, large 
>>>>>> amounts of
>>>>>> data,
>>>>>> concurrent updates, etc.
>>>>> yup, that's exactly where we are, and what we hoped to see 
>>>>> addressed by
>>>>> the working group. however, when i raised the issue that with the 
>>>>> move to
>>>>> REST it would make sense to remove the exclusive focus on RDF, the
>>>>> majority of the WG was of the opinion that we should only focus on 
>>>>> RDF.
>>>>>
>>>>> http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0029.html is 
>>>>> one
>>>>> of the threads in the archive where i was proposing to include 
>>>>> more of
>>>>> REST. since i have tried already, and should probably tread lightly
>>>>> because of my status as a co-chair, i decided to not try anymore and
>>>>> assume that the WG is focusing on RDF. you're of course free to 
>>>>> discuss
>>>>> the issue again, but it seems that so far the majority of the WG 
>>>>> is happy
>>>>> with the RDF focus.
>>>>>
>>>>> cheers,
>>>>>
>>>>> dret.
>>>>>
>>>>>
>>>>>
>>>>
>>>> Is it accurate is I summarize all of this as boiling down to 
>>>> decoupling RDF from Linked Data?
>>>>
>>>> As I stated in an earlier post, Linked Data is about:
>>>>
>>>> 1. URIs as denotation (naming) mechanism for entities (web, 
>>>> real-world, or abstract)
>>>> 2. URIs/URLs as identifiers for web resources that describe URI 
>>>> referents
>>>> 3. Structured Data representation constrained by the EAV/CR or RDF 
>>>> data models + URI behavior described above.
>>>>
>>>>
>>>> There's an artificial barrier created between Linked Data and REST 
>>>> whenever one conflates it with RDF -- which isn't about REST.
>>>>
>>>> To conclude, shouldn't this group address the decoupling of Linked 
>>>> and RDF i.e., make the coupling loose? There's everything to gain 
>>>> and nothing to lose. In a sense, the first tangible deliverable 
>>>> from this group could be an official decoupling of Linked Data and 
>>>> RDF. Such a decoupling will ultimately compliment work that will 
>>>> emerge from the current RDF workgroup etc..
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>


-- 

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