Title (Goal)

As a data user, I want a representation returned that is stable regardless of changes in the underlying object or objects

Primary Actor

Data user

Scope

 

Level

 

Author

Daniel Davis 

Story (A paragraph or two describing what happens)

Often the implementation of the system or data changes, I should be able to ask the repository for a representation that is always the same.


As a data user, I want to want to get a representation from the repository that is always the same.  As a data user I am comfortable using URIs to access data but often I expect that when I ask for a representation for a resource, I always get the same result.  Without this feature, should the underlying data be restructured I may get a different representation, therefore I cannot trust what is returned the next time I ask for the resource.

  • I want exactly same image every time I access the same URI


 

3 Comments

  1. So this use case basically boils down to providing resources (URIs) whose presence and representation follow some sort of defined contract or specification.  

    I'm imagine that this kind of pattern can be used to reduce risk of using Fedora's HTTP APIs across releases.  For example, I believe there was at least one release that could represent blank nodes in an object's RDF representation, which was subsequently removed.  If a client needed a stable representation of Fedora resources related to blank nodes, (or a representation that is not provided natively through Fedora's APIs), an extension could provide it (e.g. at /path/to/object/ext:rdf).  

  2. What is the relationship of this use case ("stable representation") to the "equivalent representation" use case?  It seems as if this use case is saying "I want the same representation of a resource over time, regardless of changes in the underlying model" and the other is saying "I'm OK with receiving a different representation of a resource over time, as long as the representations are equivalent".

    I had been thinking that content models are a way to achieve equivalent representations of a resource over time, and I guess this use case could be used to address blank node representation per Aaron's comment above.

    1. Yep.  Like elsewhere these two aspects overlap and may be productively combined.  I wanted to show the differences but it could turn out to be just a matter of degree.  The first can use a pretty rigid definition of fixity, possibly down to checksum(s) or a standardized definition of fixity quarantees.  The second implies we have a model of the essential or desired characteristics or some stewardship process that says the representation meets the declared requirements.  So the latter is at a higher level of abstraction sometimes wrapped up in authenticity.  The first can possibly achieved without a model but I don't think the second is practical in the long run without model-driven operations.