OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web ->

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.


Samit Mehta
IBM Rational Software

Steve K Speicher/Raleigh/IBM@IBMUS
"OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
10/01/2014 08:01 AM
[oslc-core] Motivation and proposal for oslc:archive property
Sent by:        


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.


The term for being archived would be


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.


I suggest this be included in Core 3 common vocabulary.


Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web ->

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]