Re: LDP interfaces in Java (based on Jena and JAX-RS)

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..
>>
>>
>
>
>

Received on Monday, 6 August 2012 18:07:11 UTC