Re: smaller example

On Mon, Jun 13, 2011 at 10:34, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote:


> To unblock the situation, I have:
> - drafted a smaller example [3], focusing on a file being updated
> - tried to illustrate examples of IVPTs in this example
> - highlighted an example of IVPT that I don't know how to handle.
>
> In this example, it would be good to see
> - where we have consensus
> - where we have disagreement
> - how we handle the outstanding example (i0) of IVPT

I think this is a good example because it at first sounds rather
simple (allowing us to flesh out the basic details we can agree on),
but still touches on the ambiguous nature of general concepts.


For instance i0 identifies "the file /home/towns.txt" across edits. We
could challenge this by doing a deletion and creating a new file.. is
it then still "the same file"? What if we rename it or move it to a
different folder? That comes down to what we mean by "the file" and
how we identify it.


When talking about the provenance of the email attachment in i5, one
can disagree on if it was Alice or Bob who "created the file" -
depending if you consider "the file stored on a certain path" (the
file slot) or "the file content evolved by Bob and David" (the file
bytes). Both these are abstract longer-stretching "views" identifying
a thing - but not necessarily the same thing.


In natural language we often deliberately form simplified equality
statements which are not logical, for instance identifying a document
printed on paper as "the same" document shown in the text editor on
screen, being "the same" as the document stored on a file. If
Frederick prints the file received by David, and his boss Gerard asks
him about the printout "Is this the town file?", David would say yes -
although it does not even have the same list of cities as
/home/towns.txt, he has not seen Edith's latest editions. Here "the
file" is used as an abstract concept above i0 - which is probably
related to the reason why the file was created (eg. places to visit
for a concert tour).


>From the file example one could argue that there are just lots of
'things' which at different abstraction levels are related and derived
from each other. So this raises the questions - are there views or
perspectives or IVPTs that themselves are *not* things? Would not such
a derived thing at a higher abstraction level be more useful to be
looked upon as a simpler/flatter/immutable "view"?


In the Web Architecture terms, this could be compared to "screenshot
of a web page", a screenshot from a browser, which is rendering an
HTML describing the current weather in Manchester (usually rain).
Let's say I've emailed such an image because something is wrong, and I
want to notify the developer.

The PNG file is a representation of the screenshot resource (the pixel
bitmap, might also be available as a BMP). This resource was itself
created as a representation of the resource of the HTML rendering
(another representation could be the DOM tree), and of course the HTML
is a representation of the weather resource.

Depending on what is the topic, I could be focusing on different
representations or resources in my exchange. If the font is too large,
the topic is on the boundary of the HTML and the rendering (I don't
care if it's PNG or JPEG)  If the PNG shows that it's sunny and it's
actually a full storm outside, I might be focusing on the weather
resource, in which case I don't care about how the PNG was created
from a certain browser, and would skip those bits of the provenance
trail.



These two examples does indeed sound like turtles all the way, which
is always a simplifying and deliberating concept, but also comes with
the danger of over-deconstruction. If you are generating provenance
information, how do you decide your abstraction levels while still
allowing different levels to somewhat agree or at least be strongly
related?


-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Tuesday, 14 June 2011 00:37:15 UTC