Fw: [Fenfire-dev] Pointers overview PEG (repost)

[Benja Fallenstein]

Argh, this was delayed for like eight hours... I'm afraid my client is to
blame. Looking forward to be back to GNU/Linux and a sane e-mail client,
soon!

-b

----- Original Message -----
From: "Benja Fallenstein" <address@hidden>
To: "fenfire developers list" <address@hidden>
Sent: Friday, August 22, 2003 3:57 AM
Subject: [Fenfire-dev] Pointers overview PEG (repost)


> =================
> Pointers overview
> =================
>
> :Author:  Benja Fallenstein
> :Created: 2003-08-20
> :Changed: $Date$
> :Status:  Current
> :Scope:   Major
> :Type:    Architecture
>
>
> By nature, Storm blocks can not be modified, as they are identified
> by their cryptographic hash. But in order for Storm to be useful as a
> backend for document storage, there must be a way to create
> updateable documents.
>
> The plan has always been to have *pointers*: A URI that can point
> to different Storm blocks over time. So every time you change a document,
> your computer creates a new Storm block containing the new version
> of the document, and makes the document's pointer point to that block.
>
> There have been prototype implementations of pointers before, but
> none of them was good enough to make a persistency commitment on.
> It's important that:
>
> - Pointers have "owners" and only a pointer's owner can change that
>   pointer's target. This is important for e.g. Web pages.
>   (Of course, everybody can create their own pointer to point to
>   their own version of a document.)
> - Full history of all documents is kept (except that you can delete
>   old versions, e.g. to save space).
> - If you have two machines, data is easily synchronized between them.
>   (If you changed a document on both machines, Storm should indicate
>   this to you, and allow you to use diff/merge tools.)
> - When you publish documents on the Internet, they retain the names
>   they had on your machine; if you made links between them, these
>   links continue to work unchanged.
> - When you download documents from the Internet and store them locally
>   on your machine, they similarly retain their names and links similarly
>   continue to work.
> - Same when you send or receive documents by mail, or when you follow
>   a link from a public Web page to a private document, etc. Even when
>   you exchange documents on floppy disks, verification works the same way.
> - Group work is possible; a pointer can be owned by a group of people,
>   and members can be added to and removed from a group. When different
>   people have edited a document concurrently, Storm indicates that;
>   it should be possible to use diff and merge tools to reconcile the
>   alternative versions.
> - Old versions are accessible as long as *anybody* keeps a copy--
>   it doesn't have to be the original author. Even the author can not
>   remove previous versions from the history of a document.
>
> I think that now I finally have a system that meets this goals
> well enough to be workable. This PEG gives an overview over this system;
> following PEGs will specify the details.
>
>
>
> Issues
> ======
>
> .. None yet.
>
>
>
> Model
> =====
>
> Pointers, under this proposal, are URIs that authoritative RDF triples
> can be associated with. These triples have the pointer as their subject
> and can have any URI as their property and value.
>
> The triples are append-only: The pointer's owner can add, but not
> delete triples.
>
> Additionally, every triple is associated with a timestamp of the time
> that the triple was created, and with a list of other, "obsoleted" triples
> (having "obsoleted" triples is not useful in triples with all properties).
> Details in another PEG.
>
> This model gives great flexibility in the way that pointers can be used.
> The simplest case are documents, as described above. The triples
> associated with a document pointer have the form, ::
>
>     <pointerURI>   version:instance   <versionURI>
>
> The ``versionURI`` is usually a pointer URI or a URI of the kind
> specified in `ref_uris--benja`__. It identifies a version of the document.
>
> __ ../ref_uris--benja/peg.gen.html
>
> The *current* version is the one whose ``version:instance`` triple
> has the most recent timestamp. The rationale for this decision is
> explained below (see `Ghost versions`_ section).
>
> The triple model allows different people in a group, or different
> machines owned by the same person, to add triples to a pointer
> independently. Thus, if you edit the same document on two machines,
> each of the machines can independently add new versions. Additionally,
> the triple model allows individual past versions to be deleted
> without impacting other versions.
>
> This is useful for other things than documents, too (which is the reason
> for choosing the extensible triple model).
>
> For example, a pointer may represent my mailbox. Each individual mail
> I have received could be put into a block and associated with my
> mailbox through a hypothetical ``mbox:contains`` property. I could then
> delete some of the mails without impacting the others. (If, instead,
> I used a document pointer that points to a list of mails currently
> in my mbox, then I couldn't delete one mail without creating a whole
> new list of mails.)
>
> As another example, imagine a group of people collaboratively posting
> items on a blog. The block could be a pointer which is associated
> with blog items through a ``blog:item`` property. This allows each
> blogger's system to create blog items independently. (If the group
> used a document pointer that points to a list of blog items, then
> two people creating blog items simultaneously would create alternative
> versions of the document, which would have to be merged.)
>
> Additionally, the pointer system uses pointer triples for a couple
> of internal tasks, to be specified in future PEGs.
>
>
>
> Metadata
> ========
>
> Every pointer can be associated with a mutable graph of metadata
> about that pointer. For example, you can associate a document
> with information about what the document is about, who maintains
> that document, how often new versions are published, and so on.
>
> This works similar to the way that we keep versions of a pointer:
> We associate with the pointer triples of the form, ::
>
>     <pointerURI>   pointer:metadata   <blockURI>
>
> The ``blockURI`` points to a block of type RDF/XML (as this is Storm,
> it must be in Sub-RDF/XML, at least for now). The most current triple
> (timestamp-wise) has as its object the RDF graph containing the
> current authoritative metadata about the pointer.
>
>
>
> Abstract concepts
> =================
>
> Pointers don't need to identify documents-- they can also identify
> people, groups, places, ideas, and so on. Internally, the owners
> of document pointers (i.e., the people who have change control
> over a document) are represented by pointers themselves, for example.
>
> Having mutable metadata associated with a pointer is particularly
> useful with abstract concepts. For example, the authoritative metadata
> about a pointer representing a person could include that person's
> e-mail address and FOAF (Friend of a Friend) information. An application
> like Fenfire could import this information when the person is mentioned
> in another RDF graph.
>
> Abstract concepts may also have representations that are shown
> when their URI is entered into a browser. For this purpose, two other
> properties are provided which are treated exactly the same as
> ``version:instance`` by Storm, but have slightly different semantics.
>
> - ``version:instance`` is for cases where the subject is a
>   document, and the object is a version of that document.
> - ``version:description`` is for cases where the representation
>   of the subject is not an instance (version, copy) of the subject,
>   but some descriptive information that explains what the subject is.
>   The object is a document of some sort, but the subject needn't be.
> - ``version:representation`` is the superproperty of the above two,
>   just stating that the object is a representation of the subject,
>   without giving semantics to that relationship.
>
>
>
> Overview of internals
> =====================
>
> The problem, then, is how to associate triples with pointers in a way
> that is authenticated (the system verifies a given triple was really
> signed by the corresponding pointer's owner) as well as permanent
> (once a triple is created, the pointer's owner cannot take it back,
> as long as someone keeps a copy).
>
> Originally, the idea was to use public key/private key
> digital signatures: Each pointer owner would have a cryptographic key,
> and would sign triples about their pointers with this key.
>
> However, digital signatures by themselves aren't really permanent,
> because you cannot rely on the private key to be kept secret forever.
> Someone may steal the key, or be able to compute the private key
> from the public key through a cryptoanalytic attack.
>
> A technique for increasing the lifetime of digital signatures is
> to timestamp them. However, this technology is heavily patented
> and thus we cannot use it.
>
> I have developed an alternative system. The basic idea is described
> in my dart, `deputy_based_signatures--benja`__. Future PEGs will give
> the details of the implementation.
>
> __ ../../dartboard/deputy_based_signatures--benja/idea.gen.html
>
>
>
> Ghost versions
> ==============
>
> One important point about pointers is that to support groupwork,
> when two people edit a document independently, when they synchronize
> Storm should notice and offer to merge the alternative versions.
>
> Before, we have archieved this by giving, with each version of a pointer,
> a couple of obsoleted previous versions of the pointer. A version
> would be current if it weren't obsoleted by any other version.
>
> So if you create three versions of a document in succession, then the
first
> version would be obsoleted by the second version, and the second version
> would be obsoleted by the third version; the third version would
> thus be current.
>
> But what happens if the second version were deleted? The third version
> would only say that the second version was obsoleted; nothing would say
> that the first version was obsoleted, too. Thus, the first version
> would suddenly seem current, again.
>
> I call this a *ghost version*: An old version from the past that
> came back to haunt you. ;-)
>
> A similar situation occurs if in a whim, you create two alternative
> versions of a document, and store one of them on a floppy disk
> but not on your main harddisk. Years later, you rediscover the
> floppy disk and copy its contents onto your new computer.
> As the version on the floppy disk, long forgotten, was never obsoleted
> by any other version (because it was removed from the harddisk before
> a successive version was created), it will appear to be "current."
>
> Again, a version risen from the dead.
>
> Ghost versions are particularly annoying when a document is published
> on the Internet. If someone discovers a ghost version and puts it online,
> it will seem to your readers as if there were two alternative current
> versions of your document-- although one of them is really but a relict
> from the past.
>
> In order to avoid this problem, this PEG specifies that only the version
> with the most current timestamp is considered "current." (The "current"
> version is the one shown when you type a pointer URI into your browser
> or follow a link.)
>
> The problem, of course, is that if two people concurrently edit
> a document, only one of their versions will be considered "current."
>
> To alleviate this problem, we *additionally* allow versions to obsolete
> each other, very similar to before. To do this, we use the feature that
> triples can "obsolete" other triples: With each
``version:representation``,
> ``version:instance``, ``version:description`` or ``ptr:metadata`` triple,
> we associate a list of previous versions (triples) that are now
> obsolete.
>
> This information isn't used by Storm to determine what is shown
> when someone enters a pointer URI into their browser. However, it
> *is* used for showing the *history* of a pointer; it may be used
> when Storm synchronizes two repositories; and it may be used when
> someone *with change control* over a particular pointer requests
> the current version of that pointer, so that they know that alternative
> versions of the pointer exist and need resolution.
>
> Sometimes, it may happen that Storm rings a "false alarm" because of
> a ghost version. However, this will only happen to the owner of the
> pointer-- someone who has change control over it and can fix the problem.
> For the pointers of others, which you find on the net, ghost versions
> will not impact you (unless you look at their history to see
> whether there are alternative versions).
>
>
>
> Vocabulary defined in this PEG
> ==============================
>
> This PEG defines the following URIs:
>
> http://purl.oclc.org/NET/storm/vocab/version/representation
>     A property. The subject is any resource and the object
>     is a representation of this object (or more accurately,
>     all representations of the object are representations
>     of the subject).
>
>     Usually used in authoritative triples about Storm pointers.
>     The *current* representation of the subject is the object
>     of the most recent triple with this subject, and one
>     of the following properties: ``...representation``,
>     ``...instance``, and ``...description``.
>
> http://purl.oclc.org/NET/storm/vocab/version/instance
>     A property. The subject is a document and the object
>     is a version of this document.
>
>     This is a subproperty of ``...representation``,
>     usually used in authoritative triples about Storm pointers.
>     While Storm treats it the same as ``...representation``,
>     its additional semantics may be useful.
>
> http://purl.oclc.org/NET/storm/vocab/version/description
>     A property. The subject is any resource; the object
>     is a description of that object.
>
>     This is a subproperty of ``...representation``,
>     usually used in authoritative triples about Storm pointers.
>     While Storm treats it the same as ``...representation``,
>     its additional semantics may be useful.
>
> http://purl.oclc.org/NET/storm/vocab/pointer/metadata
>     A property. The subject is a resource, the object is
>     a graph containing (a version of the) authoritative metadata
>     about the resource.
>
>     Usually used in authoritative triples about Storm pointers.
>     The *current* metadata graph about a pointer is the object
>     of the newest authoritative triple about that pointer
>     that has this property.
>
> \- Benja
>
>
>
> _______________________________________________
> fenfire-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/fenfire-dev
>