Re: [oslc-core] Motivation and proposal for oslc:archive property

[Steve K Speicher <sspeiche@us.ibm.com>]

Hi Lonnie,

Thanks for the feedback.  I
think it is valuable to outline the various scenarios, how they are accomplished
today and how this proposal fits into them.  I have included some
details on how these would be satisfied (or not) with today's methods and
including the proposal.

I have provided some thoughts interwoven
below...

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net

"Lonnie VanZandt" <lvanzandt@sodius.com>
wrote on 11/12/2014 05:27:48 PM:

> From: "Lonnie VanZandt" <lvanzandt@sodius.com>
> To: Steve K Speicher/Raleigh/IBM@IBMUS
> Cc: Samit Mehta/San Francisco/IBM@IBMUS, "OASIS
OSLC Core TC Discussion 
> List" <oslc-core@lists.oasis-open.org>
> Date: 11/12/2014 05:27 PM
> Subject: Re: [oslc-core] Motivation and proposal
for oslc:archive property
> 
> I claim that any practical solution has to support these five cases
for 
> resources that aren’t otherwise present in a collection:
> 1. Never existed and still doesn't

HTTP GET on this URL will return 404

> 2. Was but now is truly deleted

HTTP GET on this URL will return 404 (not found) or
410 (gone)

> 3. Archived

HTTP GET on this URL will return 200 (ok) with content
with triple that has:
   <subject> oslc:archived true.
(according to my proposal)

> 4. Not accessible due to lack of access rights

HTTP GET on this URL will return either 404 (not found)
or 406 (forbidden)
   (depending on server's access policies)

> 5. Exists, Current, Accessible, yet is selectively
hidden

HTTP GET on this URL will return 200 (ok), there will
be really no way to known things have been selectively hidden.
A client could control this by either querying based
on oslc:hidden or if results include triples with oslc:hidden in them,
then the client application can exclude them from things like user interfaces.

6. Accessible and exists (to be complete)

HTTP GET on this URL will 200 (ok) with "full"
representation of the resource

> Conversationally, the assumption that enterprise
users don’t delete 
> resources is invalid—or, at least I do not accept it as being universally
> true. In practice, I have found that systems that prevent their users
from 
> deleting content accumulate large collections of junk data as the
human 
> users naturally make mistaken entries and eventually correct those.
> Therefore, any specification or system that elects to not address
the 5 
> cases above on the predicate that “deletions are performed infrequently”
is 
> sooner or later found by its users to awkwardly handle real information
and 
> real history.
> 
I've seen a mix of these applications as well.  Going
back even to a SCM tool IBM used to sell (prior to Rational acquisition)
which had 2 operations: 1) Delete (which only marked things as deleted
and could be switched to back to active) 2) Destroy (which would remove
items from rational DB but I learned never actually removed files from
SCCS).

This proposal is not encourage tools to support an
archive option, it is only intended to provide them with a consistent way
of representing the state.  As it exists today, some tools mark them
as deleted and don't expose (GET on them returns 410) and others return
the resource and so on.

> Anecdotally, PTC Windchill allows its users to conveniently delete
> resources, such deleted resources are truly gone, but it retains a
record 
> that the resources used to exist. The query response for a resource
that has
> never existed differs from that for a resource that used to exist
but is now
> deleted. (And these are both distinct from the responses for cases
 3, 4, and 5.)

So I'm uncertain if you are proposing that I augment
the proposal I have, if so, what changes are to be made. Please let me
know.


Thanks,
Steve Speicher

> 
> —
> Lonnie VanZandt
> 303-900-3048
> Sent from Dropbox's Mailbox on Mac
> 

> On Wed, Nov 12, 2014 at 3:03 PM, Steve K Speicher
<sspeiche@us.ibm.com> wrote:
> Hey Samit, 
> 
> I would think it would make sense, I assume you do if you are asking
the 
> questions.  So the guidance you are suggesting is something along
the lines 
> of: by default, archived resources are excluded...a client would have
to 
> explicitly request them.  I guess this would be implied in dialogs
as well 
> but might be good to be explicit.  I could expect the dialogs
(and other 
> scenarios) to be heavily dependent on the context that they are being
used: 
> for example if there is an archived resource selection dialog...you
would 
> expect to see only the archived resources. 
> 
> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web -> http://open-services.net
> 
> 
> 
> From:        Samit Mehta/San Francisco/IBM@IBMUS
> To:        Steve K Speicher/Raleigh/IBM@IBMUS
> Cc:        "OASIS OSLC Core TC Discussion
List" <oslc-core@lists.oasis-
> open.org>, oslc-core@lists.oasis-open.org 
> Date:        10/02/2014 01:09 PM 
> Subject:        Re: [oslc-core] Motivation and
proposal for oslc:archive property 
> Sent by:        <oslc-core@lists.oasis-open.org>
> 
> 
> 
> Would it also make sense to add some guidance for service providers
on 
> whether to exclude / include archived" resources in search, query
and other 
> services?  I would guess that majority of scenarios would expect
that the 
> "archived" resources are automatically excluded from certain
services - e.g.
> Delegated UI for selection. 
> 
> Sincerely, 
> ___________________________________________________________________________
> Samit Mehta
> IBM Rational Software 
> 
> 
> 
> 
> 
> From:        Steve K Speicher/Raleigh/IBM@IBMUS
> To:        "OASIS OSLC Core TC Discussion
List" <oslc-core@lists.oasis-open.org> 
> Date:        10/01/2014 08:01 AM 
> Subject:        [oslc-core] Motivation and proposal
for oslc:archive property 
> Sent by:        <oslc-core@lists.oasis-open.org>
> 
> 
> 
> Motivation: 
> In typical lifecycle management tools, resources are rarely deleted.
 They 
> instead are marked with such a state as not longer being "active"
or 
> "available", some refer to this state as being "archived".
 By having a 
> uniform way to express whether a resource is in this state or not,
allows 
> for a consistent way to build queries and solutions that federate
> information from various tools. 
> 
> Proposal: 
> The term for being archived would be
> 
>      http://open-services.net/ns/core#archived
> 
> and it would take a boolean value. If this property is absent then
the 
> resource is not archived. 
> 
> This has a semantically different meaning than existing oslc:hidden
[1], 
> which indicates a hint as to whether the resource or property should
be 
> included in a UI.  oslc:archived would be used to express the
state of a 
> resource, an application may or may not decide to hide these in the
UI. 
> 
> Timeframe: 
> I suggest this be included in Core 3 common vocabulary. 
> 
> [1]: http://open-services.net/bin/view/Main/
> OSLCCoreSpecAppendixA#oslc_ResourceShape_Resource 
> 
> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web -> http://open-services.net