- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Thu, 10 Jan 2013 09:51:55 -0700
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: public-openannotation <public-openannotation@w3.org>
- Message-ID: <CABevsUF1go1bX5EXV-=9vj+64=Y6m_ALtz7B6FTUiPM0LuLMAQ@mail.gmail.com>
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
Received on Thursday, 10 January 2013 16:52:23 UTC