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

On 8/6/12 5:47 PM, Reza B'Far (Oracle) wrote:
> Kingsley -
>
> I see your point.  However, just regurgitating RDF is probably not of 
> enough value for implementers.

This isn't about regurgitating RDF. The fact that RDF intersects with 
EAV via use of URI isn't regurgitation. That's all about technology 
evolution. Likewise how Linked Data intersects with RDF etc..


> RDF already provides a mechanism for triples, etc. and there are other 
> standards that do that too (weakly typed data in form of triples).

That isn't RDF, specifically.

RDF specificity arises when you add the use of URIs as denotation 
mechanism to triples. Again, EAV/CR is very old, established, and well 
understood in DBMS communities.

Please note, every URI isn't de-referenacable. This is why the addition 
of de-referencable URIs to EAV/CR or RDF is how you arrive at Linked Data.


> Do you (or others) see any patterns around things LIKE (doesn't have 
> to be these) -
>
>  1. Abstractions involved in discovery (what am I linking to? where is
>     the identity of the provider? how does the consumer provide its
>     identity?)
>

That's part of Linked Data. Given a URI, an act of de-reference will 
resolve to a follow-your-nose friendly directed graph endowed with 
dollops of serendipity, as the Web increases re. link density.

>  1. Abstractions involved in serialization constraints for
>     implementers (whether RDF, JSON, etc. -- e.g.: is recursion
>     allowed? if so, how? etc.)
>  2. Data types allowed (are things constrained to XSD? or do we want
>     to introduce additional types?)
>  3. How are distributed quad's or graphs treated? how do they point to
>     each other across store boundaries?
>

Linked Data URI de-reference.

URI abstraction is elegant and extremely powerful, and even more so when 
combined with structured data.

A URI is a powerful data source name and data access mechanism combo 
that loosely couples:

1. data object identity
2. data access protocols
3. data object representation syntaxes and across-the-wire serialization 
formats.

Kingsley

> 1.
>
> Those are just examples.  I'm trying to see if I'm seeing the same 
> type of problems (which can be captured via the abstractions in a data 
> model) as others
>
> Best
>
> On 8/6/12 2:30 PM, Kingsley Idehen wrote:
>> On 8/6/12 5:12 PM, Reza B'Far (Oracle) wrote:
>>> Andy -
>>>
>>> Agreed on all counts.  I see the next step as pulling together the 
>>> concrete common points that are emerging in the thread in form of a 
>>> proposal which gets circulated and refined via email.  Namely, from 
>>> your email, I'd like to ask the following questions from you (and 
>>> the rest of the group):
>>>
>>>  1. Merging Kingsley's latest email bits "We are basically trying to
>>>     work out a loosely coupled architecture for data object
>>>     identification, representation, and access via:  1. URIs
>>>     2. Structured Data  3. RESTful interaction patterns." Is there a
>>>     common meta-meta-model: commonalities in how the data is shaped
>>>     (regardless of domain or application) that can form a common
>>>     starting point for the "structured data" part of Kingsley's
>>>     comments.  Then, an extensibility mechanism can be build around
>>>     it as well and the implementations (RDF, etc.) can provide
>>>     mappings for implementation-specific-implementation to the
>>>     generic extension mechanism so that there is complete decoupling.
>>>  2. I think once the "data structure" (data model, abstraction
>>>     model, whatever everyone ends up agreeing to call it) is
>>>     resolved, I believe the behavioral design around URI's, REST,
>>>     etc. will be far less complex since there is much more structure
>>>     in the existing W3C standards (http, etc.) and related work
>>>     (REST, etc.) that will constrain us from diverting from the goal.
>>>
>>> With that, it'd be great to hear thoughts around what the "data 
>>> model" part may look like and what the various opinions are.  What 
>>> are the key abstractions that we all agree on is needed in a 
>>> successful linked infrastructure?
>>
>> From my vantage point, the data model is the good old 
>> entity-attribute-value model. Every piece of data takes the form of a 
>> 3-tuple (triple). Each part of the the triple is denoted by a URI 
>> with the value part being optional since it can hold literals, typed 
>> literals, or URIs.
>>
>> Note, there is a lot on the table re. existing technology and 
>> patterns, our only struggle is getting those that see RDF and Linked 
>> Data as one to accept they are better off being loosely coupled.
>>
>> RDF and Linked Data conflation is the fundamental problem as I see it.
>>
>> As stated earlier, this group has a "deceptively simple" easy win on 
>> the table: officially decouple Linked Data and RDF. There's 
>> everything to gain and nothing to lose.
>>
>> Kingsley
>>>
>>>
>>> On 8/6/12 11:06 AM, Andy Seaborne wrote:
>>>> The separation I see as necessary is between application-specifc 
>>>> information and general LDP-platform information.
>>>>
>>>> http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jun/0018.html
>>>>
>>>> content = application-specific
>>>> metadata = platform part.
>>>>
>>>> In the submission, both are in one graph object, and that leads to 
>>>> the content needing to be RDF or at least sufficiently the 
>>>> requirements needed make it not possible for general 
>>>> XML/JSON/binary.  And that's without what Kingsley says about links 
>>>> (the links aren't findable without schema understanding e.g. <rel ).
>>>>
>>>> If the content is to to be general, that's not possible, not even 
>>>> in JSON-LD (the RDF-ness maybe retained, the exact formatting of 
>>>> the JSON lost on change).
>>>>
>>>> Erik's argument for REST depended on the endpoint understanding the 
>>>> content format.  Sometimes there are groups of applications around, 
>>>> say ATOM or HTML5, that share some structure for links.  But in 
>>>> general, that limits a data-reactive loose coupling general LDP 
>>>> storage system if it needs to grok the content to find links, types 
>>>> etc.
>>>>
>>>> If metadata is the part a general platform service understands, and 
>>>> the content is opaque, general purpose services can be built.
>>>>
>>>> If we don't like to think of it "metadata", or find it too 
>>>> restrictive because would imply only about the content, then think 
>>>> of the data objects as simply two parts, the part the general nodes 
>>>> in the system understand for any application and usage, and the 
>>>> application specific payload.
>>>>
>>>> This, I think, fits with Reza's separation taxonomy although this 
>>>> is retro fitting the thinking onto that thread.
>>>>
>>>> But the first question is just how general are we trying to be?
>>>>
>>>> If there is no commonality to extract and manipulate. we have 
>>>> either to assume application-domain-specific processing or have a 
>>>> very clear two-part model of platform and application data.  The 
>>>> submission uses RDF one unit to hold both; there are other 
>>>> possibilities.
>>>>
>>>>     Andy
>>>>
>>>> On 06/08/12 18:15, 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).
>>>>>
>>>>> 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.)
>>>>> 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.
>>>>>
>>>>> 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
>>
>>
>>
>>
>


-- 

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