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

["Lonnie VanZandt" <lvanzandt@sodius.com>]

I meant for (5) that the given user has elected for some reason to choose to exclude the resource or its kind from query results. The resources exist, they are not archived, the user is entitled to see them, and yet that user has chosen not to see them. Like a TiVo filter on commercials. This is, I assume, the intent of oslc:hidden. (If it is the case that oslc:hidden is intended to be used for hiding information according to enterprise policy, then that would be covered by the access control restrictions—or would be if the enterprise had a convenient means of dynamically adjusting access control to individual resources.)

I agree with the distinction on indicating or not indicating that a resource exists for which one lacks a need to know.

—

Lonnie VanZandt

303-900-3048
Sent from Dropbox's Mailbox on Mac

On Wednesday, Nov 12, 2014 at 17:31, BarkmeyerEdward J <edward.barkmeyer@nist.gov>, wrote:

I am going to break radio silence and agree with Lonnie on all of the below. 

 

The problem of resource deletion is a management problem, not a software problem.  You want to allow the engineer to replace and delete the model in which the tolerance on one dimension is misstated, which he discovers exactly 7 minutes after he commits the update.  You don’t want to allow deletion of a version that has moved further in the managed engineering process.  But it is all about that managed process.    

 

I am not quite sure what is meant by 5.  “Exists, Current, Accessible, yet is selectively hidden”.  There are two cases that leap to mind:

- the resource is temporarily inaccessible (active locks, server delays, whatever)

- the resource is not included because you said you don’t want it, or we have a policy that says you don’t want it unless you say specifically that you do.  This is often the case with references to ‘standard resources’.  I think the general term for this case is ‘exists, not provided’.

 

Note also that, for security reasons, an organization may want to disguise case 4.  Internally, you want to show it as present but beyond the client access rights.  For external relationships, you may not want to show it at all, or simply show it as ‘inaccessible’ or ‘not provided’ (5), without explanation.  That there is an X may itself be privileged information; similarly, that the X is tightly controlled may allow an inference.

 

-Ed

 

--

Edward J. Barkmeyer                     Email: edbark@nist.gov

National Institute of Standards & Technology

Systems Integration Division

100 Bureau Drive, Stop 8263             Work:   +1 301-975-3528

Gaithersburg, MD 20899-8263             Mobile: +1 240-672-5800

 

 

 

From: oslc-core@lists.oasis-open.org [mailto:oslc-core@lists.oasis-open.org] On Behalf Of Lonnie VanZandt
Sent: Wednesday, November 12, 2014 5:28 PM
To: Steve K Speicher
Cc: Samit Mehta; OASIS OSLC Core TC Discussion List
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

2. Was but now is truly deleted

3. Archived

4. Not accessible due to lack of access rights

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

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.

 

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

—

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