Re: Question re 5.2.5.2

Howdy Rob.

> 5.2.5.2 states that a system MUST delete the describing RDF Source 
> when a Non-RDF resource is deleted.  We were wondering why this was 
> a MUST, given some of the other points in the specification.  

My recollection is:

1: At the time (this has since changed), there was no LDP-defined way to 
find orphaned LDP-RS's and people were reluctant to leave trash lying 
around that even a well-intentioned client had a hard time cleaning up.

2: People liked the symmetry of responsibility around who and when 
deletion of the LDP-RS's happened.

3: (At least some of us) figured any logging could still be handled, as 
you're doing now for example.

4: TimBL "encouraged" us to give clients guarantees (server Musts) at his 
first deep review.

I can't think of anyone who I would anticipate -1'ing a proposal to change 
to SHOULD.
ala TallTed's statement today, that would not change compliance of 
existing implementations so it might be low resistance and would not cause 
Yet Another LC


> In 6.2.4 it says that it is acceptable to remove triples from other 
> resources, but also acceptable and common for LDP servers to not do 
> this, and that clients should not rely on consistent behavior. 

True as a general statement, hence true in HTTP.
Most HTTP-based specs constrain HTTP for the set of [HTTP] resources the 
new spec is concerned with though, so LDP saying how containers and their 
members interact is not surprising, is it? 

LDP leaves to you free, for example, to create *2* "associated" LDP-RS's 
instead of one.  One ("LDP's") has a lifecycle constrained by LDP, the 
other is simply outside LDP so you do what you want with it.  If you also 
happened to define "yours" to be a "superset" of "LDP's", no one could 
argue that conflicts with LDP.

Or create only one LDP-RS (yours) and forget about LDP's optional one. 
Iconoclastically, you could even use the same response link header (no 
spec has exclusive use of the link relations), and in effect the only 
observable difference would be that it doesn't disappear after the LDP-NR 
is deleted.  That doesn't mean you've violated LDP, it means that the link 
relations are not specific enough [waves to Sergio] for clients to 
differentiate between LDP's and yours.  c'est la vie; lemons or lemonade, 
you decide.


> * Change of Visibility.
> For systems that support "soft" delete by just removing the resource
> from what is publicly visible, maintaining the metadata about the 
> resource could still be important.  For example, in a repository of 

We have products that do this sort of thing.  They treat soft-delete as a 
state change (not deletion).  In the use cases you cite, that actually 
sounds from the outside like a more faithful use of HTTP.

> * Additional Metadata

It sounds like you are assuming that the LDP-RS is the only place where 
that metadata could live.  Which in an RDF world is kinda confusing, so 
maybe I'm missing your point.  Certainly the "2 not 1" trick is an option, 
but maybe you only have 1 kind of metadata.

There are all sorts of other possibilities; none of them frankly as 
obvious as "let the server worry about deleting the metadata", but for 
completeness these spring to mind:
- 3xx from deleted (303 in particular fits the semantic)
- 410 from deleted with response link header to tombstone
- soft delete as state change, one of the above for hard/forced delete
- logs probably append-only anyway


Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead