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

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