Re: Marmotta early implementation report

Hi Steve,

On 28/03/14 20:48, Steve Speicher wrote:
> Thank you for this feedback, good work..  I haven't had a chance to
> actually run your changes but I have responded to your questions below.

Thanks. My comments inline too.


>>   * 4.3.1.6 Reuse Predicates: conforms Overlapping with 4.3.1.5?
>
> Perhaps not 100%, though I could see how they could be combined but I don't
> really see any hard in leaving as-is either.

Just an editorial comment, not really blocking.


>> 1. Update LDP Ontology http://www.w3.org/ns/ldp# with the terms missing
>> from the Spec
>
> We have an outstanding request to have this properly updated, for now you
> can find what is supposed to be served there at: www.w3.org/TR/ldp/ldp.ttl
> Apologies for the confusion and taking your time to review the outdated
> content.

No problem. We just wanted to assert it.


> 2. Add ldp:NonRdfResource to the Spec. and LDP-Ontology
>>      (URI is never explicitly used in the Spec)
>
> It is in ontology but is ldp:NonRDFSource.  I'll look to see where it
> should fit in the spec.

Then it should be mentioned in the spec. Perfect, thanks.

>> 3. Extra Link: Headers on Requests to LDP-R
>>     * LDP-NR: Link with href of the corresponding RDF-RS with type "meta"
>
> Not sure why this is considered missing, we don't use this.

This is related with ISSUE-15. But the thread about such proposal of 
using rel="meta" for 5.2.3.12 has never been actually addressed:

http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0037.html


>>     * LDP-RS: Link with href of the corresponding RDF-NR with type
>> "content" (if present)
>
> Can you elaborate on where this is missing from?  I don't recall this being
> something we intended to have.

Basically we proposed that when requesting a LDP-RS that was added upon 
the creation of a LDP-NS (5.2.3.12), the existence of the LDP-NS should 
be announce too.

And, to keep it orthogonal with the rel="meta" proposed in the previous 
point, something like rel="content" could be used for such purpose.

This concern has its background in the Linked Media Principles that the 
former project of Marmotta (LMF) was defining:

https://code.google.com/p/lmf/wiki/PrinciplesLinkedMedia


>> 1. 5.2.3.11 Is using an URI that was previously DELETEd considered
>>     "re-using"? (see also 6.1.2)
>
> Yes, by "using" meaning that after a successful DELETE request, and
> requests on that same URI should return 404/410 and server should not
> reassign a URI (reuse) if another member is created.

Got it. Let's how we can address it, but now it's clear.


>> 2. 5.2.3.12 (also 5.2.8.1) Link to the LDP-RS rel should be "meta" or
>>     "describedby"? (ISSUE-15)
>
> describedby, rel=meta doesn't exist...we were using it conversationally.

This goes to the point above. Not so much to say.


>> 3. 5.2.3.12 Is the LDP-RS also "ldp:contains" by the LDPC?
>
> No, not required.  Though I could see where some implementations may
> maintain a LDPC on the side of these metadata LDP-RSs.

With 5.2.3.12 there are actually three possible alternatives that are 
not really well described:

a) The LDP-NR is the one contained:

     <LDPC> ldp:contains <LDP-NR> .
     <LDP-NR> dct:isFormatOf <LDP-RS> .

b) The LDP-RS is the one contained:

     <LDPC> ldp:contains <LDP-RS> .
     <LDP-RS> dct:hasFormat <LDP-NR> .

c) Both are contained contained:

     <LDPC> ldp:contains <LDP-NR> ;
            ldp:contains <LDP-RS> .
     <LDP-NR> dct:isFormatOf <LDP-RS> .

Personally the last one is not correct FMPOV. But with the current spec 
the first two could be completely valid. So I guess we need to clarify 
such detail.


>> 4. 4.2.5  When an LDP-RS is deleted and the LDP-RS is associated with
>>     an LDP-NR, should the LDP-NR be deleted too? (see also 5.2.5.2)
>
> Yes.

Perfect.

>
>> 5. 5.2.7.1 (also 4.2.7) Is it allowed for the LDP Server to restrict
>>     the properties changed by a PATCH request (analoguous to 4.2.4.1)
>
> Yes, 4.2.1.6

OK.

>> 6. 6.2.4 Is it allowed to modify properties of a LDPC where a LDPR was
>>     deleted from, e.g. dct:modified?
>
> I don't see anywhere where it isn't allowed.  One could expect a server
> impl to auto-update this property.  Though I would only expect certain
> clients serving some admin role to be allowed to modify these type of
> properties.

In this case the question comes from the server-side. Basically if a 
resource deletion was considered a modification of the LDPC, so altering 
such administrative data.


>> Feedback to any of those points would be very welcomed, particularly to
>> the open issues and questions. A good questions now is how to automatize
>> these checking by assembling a proper test suite.
>
> As we are working with our own implementations that are being positioned as
> LDP-extensions and interested in an automated way to test (and extend the
> tests).  I will follow up on a separate thread on this, it is along the
> lines of your RESTassured junits.

We already started to move forward implementing the actual Test Cases 
(see the other thread). My idea is to produce a generic implementation 
that could be plug-in on top for testing any implementation.


>> In addition, I'd like to point that we, as well of all other potential
>> implementations, would benefit of keeping the sections numbering as stable
>> as possible in these last revisions of the spec.
>
> Agree, we decided to move things around a bit and adopt better anchors to
> help with consumption.  The intent is hopefully it will be fairly stable
> from here, at least you can reference the individual sections by URI (and
> not number as respec generates those section numbers).

Exactly, at least having stable to refer and be able to refresh would 
hep to track the changes from the implementations.

Thanks for all your feedback.

Best,

-- 
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at

Received on Thursday, 3 April 2014 07:32:48 UTC