Annotation updated timestamp

[azaroth42]

To avoid mandating a versioning system, we should allow the description of resources that are modified in place. Thus the current 'created' time may be insufficient, and we should thus allow 'modified' as well.

Proposal:

• Resources MAY have dcterms:modified (json-ld: modified) as a property, with the value being an ISO8601 timestamp for when the resource was most recently modified

[iherman]

On 4 Nov 2015, at 01:38, Rob Sanderson notifications@github.com wrote:

To avoid mandating a versioning system, we should allow the description of resources that are modified in place. Thus the current 'created' time may be insufficient, and we should thus allow 'modified' as well.

Proposal:

Resources MAY have dcterms:modified (json-ld: modified) as a property, with the value being an ISO8601 timestamp for when the resource was most recently modified

+1. This is quite a standard thing to do

[BigBlueHat]

This issue and #21 are buzzing in my head as I discuss (im)mutability with @jbenet and others working on @ipfs.

If/as we discuss "distributed annotation" such that they may be "birthed" offline and later appear on the public web, we face several issues concerning identity and change over time.

If I create an annotation in my browser, what URI does it get (see #21)?

If I send it into the world and multiple copies of it are made, would it matter if I later changed the original and recorded a modified date?

Wouldn't it be better to distribute a new annotation which references the original via a predecessor-version or prov:wasDerivedFrom or similar relationship (see #21 again)?

So...I'm OK having the modified (or updated) key/value available, but...I fear it implies something--in the context of distributed annotation--which is not actually implementable...in the same way I can't "modify" an email I've sent...including the one generated by my typing this in GitHub. 😉

Actually...this text box is a great example. It does store updated_at (see this example) and gets distributed via email and likely consumed via the API into who knows how many possible tools. If I update this later, few(er) things will get triggered, notified, etc.

The value of updated_at in this case, then, is anthropological, and really only signals that the copy I have in my hand (from email) may no longer === the thing I get off the Web...hmm...

Fun problem. 😄 Hopefully that stream of consciousness is helpful. 😉

What I'm thinking now:

• we add modified (or updated to match AS)
• we nail down Annotation alsoKnownAs <uri> #21 such that a chain of identifiers can be built up as the annotation moves about the Web and off the Web
• we explain that modified really only refers to the copy you have in hand--which may be tricky if the @id stays the same while a via "chain" gets appended too with each stored copy...

😖 Certainly this is simpler when you can only append in the first place. 😉

k. Someone else chime in before I think myself back through the loop. 🔁

[BigBlueHat]

So, our spec (and most other W3C specs, I'd reckon) use the dcterms:related term as a Link Relationship to point to previous drafts of a specification.

From a protocol and data model perspective this seems prudent for use with updated--or in place of it.

Such that I could do the following:

{
  "id": "http://example.com/annoReplaceMe",
  "via": "http://example.com/2015/11/5/annoReplaceMe",
  "target": "http://w3.org/",
  "body": {
    "content": "really great site!!1!"
  }
}

and then...

{
  "id": "http://example.com/annoReplaceMe",
  "via": "http://example.com/2015/11/9/annoReplaceMe",
  "target": "http://w3.org/",
  "body": {
    "text": "Really great site!"
  },
  "replaces": "http://example.com/2015/11/5/annoReplaceMe"
}

Maybe that's a bit nuts. 😄

In this case, via is being used in a similar fashion to HTTP's Content-Location header (i.e., this is where the content actually lives, but id is what I want to refer to it as).

When replaced, the id value is the same--amounting to an "overwrite" or "update" request made to the consuming graph (or storage system). The replaces value is the "content location" (expressed in via of the earlier annotation) and works in the same way it does with W3C specs:

• the primary URL doesn't change
• updates replace the primary URL
• updates get archived (if desired) at their via URI

Too crazy? 😸

[jbenet]

I would really advise against using HTTP for naming anything (ids) that is meant to work across locations, meaning if an annotation can be made in a host (perhaps disconnected) and then served by a variety of other hosts, it is best to use a URI of some sort.

In IPFS, I would use either a keypair (naming the object as /ipns/<cryptographic_hash(public_key)>), or use an object nested under a keypair (naming the object as something like /ipns/<cryptographic_hash(public_key)>/annotations/<uuid>). This would be a name which resolves to an immutable object representing the state at a particular time (think of it like git-style versioning). Could even point to version history chains, if desired.

[BigBlueHat]

So, one option would be to use a UUID (as @timbl suggested at TPAC), but use it as the id value--obviously this makes these id's non-dereferencable.

However, if we require (I know, I know...) a via chain to be present such that the minimal published Annotation becomes:

{
  "id": "...uuid...",
  "type": "Annotation",
  "via": "http://annotation-server.example/~bigbluehat/...uuid...",
  "target": "http://example.com/"
}

Before publication it would be just the id, type, and target. At publication, the via URL would get added-- the expectation being that others can use the IRI's stored in via as locators (though that wouldn't be a requirement, I don't think).

Here's via's definition from RFC4287:

The value "via" signifies that the IRI in the value of the href
attribute identifies a resource that is the source of the
information provided in the containing element.

A copy made by @jbenet in IPFS +/- some additional statements could then look like:

{
  "id": "...uuid...",
  "type": "Annotation",
  "via": [
    "http://annotation-server.example/~bigbluehat/...uuid...",
    "https://ipfs.io/ipfs/...ipfs hash of annotation content, public key, etc..."
  ],
  "target": "http://example.com/"
}

Annotation systems (offline web browsers, ebook readers, etc) could make Web Annotations, and publish them later.

Obviously this is beginning to effect protocol topics...so, tagging it that way also.

[iherman]

We are getting into similar discussions in the publishing IG re publications. Influenced by that discussion, I wonder: why do we need that 'via'? If we adopt the approach of (conceptually) separating the ID and the locator, then we can simply say

{
  "id" : "… any URN, uuid or other",
  "url": "http://bla.bla.bla <http://bla.bla.bla/>"
}

If an application wants to have something reflecting provenance, it can use provenance related vocabularies. We should not dictate that.

Just a thought…

Ivan

On 16 Nov 2015, at 16:49, BigBlueHat notifications@github.com wrote:

So, one option would be to use a UUID (as @timbl https://github.com/timbl suggested at TPAC), but use it as the id value--obviously this makes these id's non-dereferencable.

However, if we require (I know, I know...) a via chain to be present such that the minimal published Annotation becomes:

{
"id": "...uuid...",
"type": "Annotation",
"via": "http://annotation-server.example/~bigbluehat/...uuid...",
"target": "http://example.com/"
}
Before publication it would be just the id, type, and target. At publication, the via URL would get added-- the expectation being that others can use the IRI's stored in via as locators (though that wouldn't be a requirement, I don't think).

Here's via's definition from RFC4287 http://tools.ietf.org/html/rfc4287#page-22:

The value "via" signifies that the IRI in the value of the href
attribute identifies a resource that is the source of the
information provided in the containing element.

A copy made by @jbenet https://github.com/jbenet in IPFS +/- some additional statements could then look like:

{
"id": "...uuid...",
"type": "Annotation",
"via": [
"http://annotation-server.example/~bigbluehat/...uuid...",
"https://ipfs.io/ipfs/...ipfs hash of annotation content, public key, etc..."
]
"target": "http://example.com/"
}
Annotation systems (offline web browsers, ebook readers, etc) could make Web Annotations, and publish them later.

Obviously this is beginning to effect protocol topics...so, tagging it that way also.

—
Reply to this email directly or view it on GitHub #96 (comment).

---

Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

[azaroth42]

Some design considerations I'd like to propose, based on the above discussions:

• We should avoid mandating a versioning model. Some systems will do immutable resources with replacements, some will simply modify in place. There's advantages and disadvantages for each, and we're not going to solve that. Picking one is splitting the community unnecessarily.
• We should (continue to) make use of the Linked Data best practices, and notably that the URI for a resource should be dereferencable and provide useful information.
• We should not invent relationships when they already exist, and we should prefer well used and web-focused ontologies. So in this case, I think that DC and the IANA rels would be preferable to PROV-O.
• We should not prevent the use of non HTTP/S URIs, but this is the Web Annotation WG and recommending their use seems entirely consistent with our mission and charter.

Thus, along with #21, we can fulfill these with iana:via and dcterms:modified. We might consider using updated as the key for modified, per #102. We can allow UUIDs or any other URI as the object of iana:via, but id should be HTTP/S and provide useful standards based RDF compatible data.

[BigBlueHat]

@azaroth42 given those statements, should we consider this as a possible "offline-first" annotation?

{
  "uuid": "...uuid...",
  "type": "Annotation",
  "target": "http://example.com/"
}

Note the lack of @id or id. Until it's published, then, it has no known deferencable id and as such, the use of id for an offline annotation SHOULD be avoided. However, at publication (to the Web or some other connected URL minting thing), the id value MUST be set such that it becomes a proper Web Annotation.

Does that seem like a plausible path?

My concern is having a "cloud requirement" for the initiating act of annotating--by which I mean a sign-up process to some service "on the Web" which will give the annotator a "namespace" in which to create (future-use-ready) dereferencable URLs...but at the cost of the sign-up, terms of service, pre-annotation process requirement, etc, etc.

My hope is to find a path where, me and my offline machine can make annotations with the same requirements as me and my book. If I have a "highlighter," I can annotate. No additional storage space or permission required.

If we can come up with a way to do that and create a dereferencable id value, super! If not, we should at least given DPUB (and may others) a process for "pre-Web-publication" annotations.

[iherman]

On 16 Nov 2015, at 22:20, BigBlueHat notifications@github.com wrote:

@azaroth42 https://github.com/azaroth42 given those statements, should we consider this as a possible "offline-first" annotation?

{
"uuid": "...uuid...",
"type": "Annotation",
"target": "http://example.com/"
}
Note the lack of @id or id. Until it's published, then, it has no known deferencable id and as such, the use of id for an offline annotation SHOULD be avoided. However, at publication (to the Web or some other connected URL minting thing), the id value MUST be set such that it becomes a proper Web Annotation.

Does that seem like a plausible path?

My only comment is that we should not cast in concrete the usage of UUID. It should be something generic, allowing for URN/URI-s as well. Although not really relevant for annotations, but communities may have their own identifier schemes (in the case of publishing people may want to use ISBNs or DOIs, all of these have URN/URI equivalents).

My concern is having a "cloud requirement" for the initiating act of annotating--by which I mean a sign-up process to some service "on the Web" which will give the annotator a "namespace" in which to create (future-use-ready) dereferencable URLs...but at the cost of the sign-up, terms of service, pre-annotation process requirement, etc, etc.

My hope is to find a path where, me and my offline machine can make annotations with the same requirements as me and my book. If I have a "highlighter," I can annotate. No additional storage space or permission required.

If we can come up with a way to do that and create a dereferencable id value, super! If not, we should at least given DPUB (and may others) a process for "pre-Web-publication" annotations.

---

Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

[iherman]

Discussed on the call: this issue is closed per http://www.w3.org/2015/11/18-annotation-irc#T16-28-42 on the original request; the discussion on the identifiers should move over to issue #21

[azaroth42]

Done: http://w3c.github.io/web-annotation/model/wd2/#lifecycle-information