Question re 5.2.5.2

Dear all,

To introduce myself in more detail before asking stupid questions :)

I'm Rob Sanderson, at Stanford University.  My role at Stanford is
information architect and technical liaison for the libraries and archives
with organizations such as the W3C.  Within the W3C I am co-chair of the
nascent Web Annotations Working Group [1], and have been co-chair of the
related Open Annotation Community Group [2] since its inception.

Stanford's interest in LDP is related to our work with Annotations and with
a community developed, digital repository system called Fedora [3,4] -- we
feel that LDP would provide a great basis for implementations in both of
this areas.

While testing Fedora for LDP compliance, we discovered some points we would
like clarification on, though completely understand that this is very late
in the game, as per the call today.

In particular:

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.

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.  Further, in Note
3.1, Containers are resources and may also represent additional data that
is valuable to the agents that access it.

The use cases we have in mind for when we would either work around this
requirement or simply fail to be compatible are:

* Tombstones.  For systems that do synchronization (aka harvesting) of
resources, having a record that the resource was deleted and when that
occurred is important to ensure that it can synchronize correctly.  A
recent spec in the library world on this top is ResourceSync:
http://www.openarchives.org/rs/toc

* 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 scholarly
communication, you might want to hide a paper from view without deleting
all traces of its existence. This could be because the paper was retracted,
because it was put under embargo and will be re-published in its entirety
later, among others.

* Additional Metadata
Silently deleting all of the metadata about a resource is potentially
dangerous for logging, auditing/compliance and so forth.  Any provenance or
workflow metadata such as the record that a system actually /did/ delete
the NR, when, by which sub-system, etc etc are important to maintain.  Any
hand-created metadata is expensive to reproduce if the resource is
re-created.


Our current work around is:

* create a new RS when an NR is deleted by copying the describing RS to a
new URI
* add a link header to it (rel to be determined) on the response
* update any references to the RS to this new "tombstone" RS

Thoughts?

I hope to be able to commit to a timeframe on Indirect Container
implementation by next call.


Best regards,

Rob Sanderson

[1] http://www.w3.org/annotation/
[2] http://www.w3.org/community/openannotation/
[3] https://wiki.duraspace.org/display/FF/Fedora+Repository+Home
[4] https://github.com/fcrepo4/fcrepo4


-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305