New Draft comments: Level 1

Hi,

Some notes after reading the section on Level 1 "Simple Annotations":
http://www.openannotation.org/spec/future/level1.html

I hope this helps.

Cheers,

Antoine

-----


1. It is very good to have textual annotations in this section. I feel however that the simple annotations could include something on (semantic) tagging, which is a very common case, too--and also one that may be thought as suffering from OA complexity.


2. "An Annotation is the expression of a relationship between two or more resources in the form of a serialized graph."
I find this confusing. Serialization is a representation in one syntax. This hints that an annotation serialized in RDF/XML is not the same as an annotation serialized in Turtle... I would remove "in the form of a serialized graph".
Note that this sentence also contradicts the case of bodiless annotations.


3. "The oa:hasBody and oa:hasTarget relationships should be used in queries to match Body and Target."
Not very informative, could be dropped.


4. "Requirement: Find all of the body resources" -> "Requirement: Find the body resources"


5. The wording of first paragraph of 1.1.1 could be enhanced.  I understood something like this:
[
Accessing the general content type (Image, Audio or Video) of an Annotation's related resources is useful for applications. Rather than representing this information at the level of the Annotation itself, using sub-classes of the Annotation class, the Open Annotation models uses specific typing of the Body and Target resources. It also allows expressing simple types, as opposed to forcing applications to re-use long lists of technical MIME types.
]
By the way I admit I have doubts, why it's not better to just let (some) applications access only precise technical information (as represented using dc:format), rather than recommending the current intermediate level, the relevance of which is unclear to me. Can a connection be made between this sub-section and application scenarios, which would make the requirement more explicit?


6. Playing the devil's advocate, I don't see why the DCMI Type Vocabulary is being re-used, if one very important element (Text) should not be used as it is recommended there...

I also think the table with the selection of types could be removed with a list of hyperlinks, somewhere in the paragraph:
<a href="http://purl.org/dc/dcmitype/Dataset">Dataset</a>, <a href="http://purl.org/dc/dcmitype/Image">Image</a>, etc.
The fact that the table is incomplete could confuse readers. And besides the one for Text, the definitions are quite intuitive and seem not worth being repeated in the OA spec.


7. I'm not sure why, but I really prefer "Embedded Textual Bodies" over the previous version's "Inline bodies" :-)


8. "Previous annotation systems that only permitted textual Bodies might have used a property with a string literal"
-> "Some previous annotation systems have used a property with a string literal to represent textual Bodies"
(the current wording is not specific enough: OA is also using properties with string literals, after all)


9. "It is RECOMMENDED that the ContentAsText resource be identified with a UUID URN"
Why a UUID URN? And why is it recommended? For many people in the RDF community, even if you convinced them to have the one-step indirection using cnt:chars, they would still think blank nodes are the perfect choice for such a situation.

10. "the dctypes:Text class SHOULD also be assigned alongside the ContentAsText class, as there may be other uses of ContentAsText that encode resources other than plain text."
Why bother with explicitly typing resources as ContentAsText, if it doesn't bring the desired information? As such it seems the mere use of cnt:chars to link the textual body to the literal should give enough information.


11. "The MIME type of the text should also be given using the dc:format property"
Is it a SHOULD?


12. "As URIs are considered as opaque strings, annotation systems may not discover annotations on fragment URIs when searching for annotations on the resource by means of its URI without a Fragment component."
OK, but an example would help. Also, this argument seems weaker: to match such requirement, even with a fragment-free URI, one would always need extra statements (using e.g. dcterms:isPartOf) so that applications can access a part (and its attached annotations) from a whole.


13. "Even if a MIME type does have a fragment definition, it is often not possible to describe the segment of interest sufficiently precisely.
It is not possible to determine with certainty what is being identified, as the same fragment string might be possible in different specifications."
A quick example would help, for both statements.


14. On 1.2 Annotation Provenance: I find it good that the problem is more introduced now on the business-level, rather than on the technical one (graphs). But one could add to "deserves credit for their contribution" that sometimes it is blame that is deserved ;-)
In fact it would be good to add a short sentence relating to more general problems of 'trust' and 'reputation'.


15. Have we cancelled out the mappings to Dublin Core that were in the previous version (oa:annotatedBy and dc:creator, oa:annotatedAt and dcterms:created, oa:serializedBy and dc:publisher)?
I agree the PROV mappings are useful, but we could keep the old ones,, if they are still correct. Not everyone will be interested in checking the PROV spec to see whether they allow to link between OA to DC.


16. "the agent responsible for asserting the triples in the Annotation graph"
The notion of annotation graph is not defined earlier. And I think anyway this bit can be simplified into a less confusing: "the agent responsible for creating the Annotation"


17. oa:serializedBy and oa:serializedAt also miss an introduction for the notion of Annotation graph.

There's also the problem of attaching these (data-level) properties to Annotation resources, not named graphs or something like OAI-ORE's ResourceMap... The definition makes the motivation quite clear, which partly alleviates the issue. But it may be useful to drop an editor's note saying that this attachement to Annotation resources may be revisited at a later stage, pending, e.g., decisions of the RDF Working Group on Named Graphs.


18. It's not a crucial issue now, but in case the "core" part becomes too big, I'd suggest moving the part on Agents (1.2) elsewhere in the spec. I find it a bit detailed and not enough focused on Annotation, for a part on simple annotations. The section on Motivations (1.3) seems more central to me, for example.


19. "by using the SKOS Concept hierarchy."-> "by using a SKOS Concept hierarchy."


20. All examples in the table of Defined Motivations should be lowercased, following the convention on instance identifiers. E.g. oa:Editing -> oa:editing.


21. Is the table describing motivation concepts complete, w.r.t skos:broader hierarchical links or skos:related associative links? I was wondering for example whether 'classifying' and 'tagging' are connected together and/or to 'linking'.

Received on Sunday, 6 January 2013 15:48:03 UTC