Re: Annotation Concept vs Document (was Level 1 comments)

Hi Antoine, all,

I don't think it's feasible for the current version to change this from how
it stands to mandating the identification (or at least modeling with a
blank node) of both the concept and the document separately.  It was
discussed at length at the first CG face to face as well as explicitly
rejected in OAC previously. I cannot speak for AO, Annotea, Annotator,
Pundit or other existing systems in terms of design choice and discussion,
but the vast majority that we looked at also did not have two nodes.

My proposal is to:
* Add an editor's note to the spec in the Provenance section saying that it
is under discussion, and especially if the Named Graphs specs reach
maturity, it may change in the future.
* Increase the detail in the Provenance Mapping Appendix to allow it to be
used in practice to identify the Concept separately from the Documents, to
enable systems that do have a requirement for this to play in both worlds.

To attempt to summarize the issues:

The advantages of two nodes:
* Explicitly distinguishes the concept and the document that describes the
concept (see ORE Aggregation vs Resource Map)
* Could reuse the same existing predicates attached to the two nodes, eg
dcterms:creator and dcterms:created, instead of inventing our own to
distinguish concept and document
* Likely to fit better in the future if and when Named Graphs are properly
standardized
* Could avoid equivalentTo in place of owl:sameAs for the republishing case
of simple format transformation (but not if the graph changes)

However:
* You still need two identifiers for the Annotation concept, due to the
trust and dereference issues.
* There's significant cost in terms of 303 implementation and URI
maintenance.  You can't just push an Annotation document up on a website
and be done with it, you really need some publishing infrastructure to do
the right thing.
* There's a not insignificant cost in additional number of triples.
* We still need equivalentTo for when there is any change to the
Annotation, such as taking an embedded resource and publishing it with an
HTTP URI.
* It's still likely to change in the future, given Named Graphs and so
forth.

In other words, it's again the choice between preciseness of modeling and
ease of implementation.

To put my cards on the table, I'm personally in favor of the two node
approach, as it seems significantly cleaner and number of new
identifiers/triples has not been a fundamental axis for design decisions.
Or at least until the textual body discussion :)

Rob