Dear all, Thanks to the editors for putting this document together. As far as a FPWD goes, it looks in good shape already. I have reviewed part of this specification, and produced a list of comments/remarks/suggestions, described below. They are ordered according to their occurrences in the document, thus, mixing minor and more important issues. If my comments are unclear, apologies, don't hesitate to ask for clarifications. I don't expect all issues can be addressed before publishing FPWD. However, it would be good, for those that are a bit more fundamental, if a NOTE was inserted in the document indicating that an issue needs to be investigated. This would make it clear to the potential reader about the work in progress nature of the specification. Given this caveat, I am happy with going ahead with publication of FPWD. 1. abstract: Terminology: I find it strange that the Web Annotation DATA MODEL specifies ... a structured description MECHANISM. Is this a mechanism? It is a description format and its meaning. The mechanism it enables is sharing ... 2. abstract: "annotations are ... used to EXPRESS INFORMATION about ..." Later: "commmon approach to EXPRESSING these annotations ..." "for EXPRESSING annotations ..." What does this use of EXPRESS mean? 'express annotations that express information' More generally, I found the few occurrences of the verb EXPRESS in this document confusing. 3. section 1: the Web Annotation SYSTEM No system has been defined so far. We only mention here a Web Annotation DATA MODEL. 4. section 1.1 The convention of using "Annotation" vs "annotation" has not been defined. What does it mean? Likewise, for Body/body and Target/target, I believe. 5. section 1.1. To provide a standard description MECHANISM (see note 1) To provide a STANDARD description mechanism -> drop STANDARD, maybe say 'normative' goal of this STANDARDIZATION process ?? we should not refer to standardisation in a recommendation 6. Section 2: the following principles EXPRESS (three times) 7. Section 2: "The Target or Body resource may be a specific REPRESENTATION of a resource." I am not sure I understand. a resource may be a REPRESENTATION of a resource? Is it what is meant? I don't follow. 8. Section 3.1 "The JSON serialization of the Annotation MUST BE available at that URI." Is content negotiation supported? While I support this Linked Data principle, I was not clear why this had to be specified so early in the description of the DATA MODEL. Are we also sure that a MUST is required here. Imagine a broken uri, a web site going down. By some means, I have obtained a representation of an Annotation, but because the URI cannot be dereferenced, this specification seems to imply that this representation cannot be intepreted, because an "absolute requirement has not been met" (rfc2119). 9. All annotations must be instances of the class Annotation. What does this mean in JSON context? Is it therefore mandatory to have "@type": "oa:Annotation"? 10. Usage of MAY/SHOULD, etc Vocabulary table in section 3.1: "There SHOULD be 1 or more oa:hasBody relationships associated with an Annotation but there MAY be 0." It is recommended to have 1 or more, but at the same time it is truly optional to have 0. I find this strange. In fact, the case of 0 body is actually discussed in 3.2.8, so it is a truly legitimate situation. 11. section 3.2.1 I would suggest not using the plural form "Simple Textual Bodies" because we cannot search on "Body". Search everywhere for bodies (but also targets, etc). PROPOSED: rewrite as "Simple Textual Body" 12. "The media type of the body MUST be text/plain" I don't understand. Don't we consider the case where the body is a text, directly provided, as opposed to a resource. So, why media type? it's when we have a resource. Or, is it suggested that we define the media type of a body text to be of media type text/plain, as if we were dealing with a resource as opposed to embodied text? 13. The Body MUST be a resource, other than the exception described in 3.2.1. Then we should not use MUST. Both Body and Target SHOULD have a class ... not if body is text. I suppose these may be remnants of the community specification, when embodied text was not supported. 14. Section 3.2.3. The body and target should have exactly one dc:format property. Can an annotation be over a resource, whose representation is obtained by content negotiation? This means that multiple dc-format may be supported, one for each media type supported by the body/target resources. Alternatively, if it is the expectation that only one repesentation is expected for the resource, than we should make it clear here. 15. Section 3.2.6 "In the Linked Data" ?? Maybe "In the Linked Data APPROACH"? 16. Section 3..3 "the person or machine responsible ..." Why limit ourself to persons or machines? What about organizations? Same comment for vocabulary table for oa:annotatedBy. Actually, later, the foaf:Organization allows for Organization annotators. " useful for both ADVERTISING ..." What do you mean by advertising? Is it publishing/discovery? 17. Section 3.3 "If a more accurate model with distinct identifiers is required for particular use cases, then the model expressed in Appendix A is recommended." This sentence leaves the feeling that it is a different model. It is not. It is a refinement that provides further details. " model EXPRESSED in Appendix A" -> "model DESCRIBED in Appendix A" 18. Appendix A. Can we confirm that it is a normative appendix. (It is currently is, I am happy with this). 19. Section 3.3, Vocabulary: oa:annotatedBy If find the normative language unclear. It should specify what an implementer should do. "there SHOULD be exactly 1 oa:annotatedBy relationship per Annotation, but MAY be 0 or more than 1, as the Annotation may be anonymous, or multiple agents may have worked together on it." By using MAY, we mean something is truly OPTIONAL. Are we suggesting that arity 0 or more than 1 can be optionally supported? "Annotation may be ANONYMOUS" -> what do you mean by ANONYMOUS? without uri? blank node? 20. The normative constraints for annotatedBy and annotatedAt differ. For annotatedAt: MUST NOT be more than 1. What if annotatedBy has multiple instances? I would suggest that the text should say that multiple instances of annotatedBy are permitted, but they are expected to all occur at the same time (specified by annotatedAt). 21 oa:serializedBy: "the object ... likely to be software" Again, why not organisation? How should we interpret "likely"? Do you mean SHOULD? 22. oa:serializedBy is subProperty of prov:wasAttributedTo is problematic. If PROV reasoning is applied, it may lead to incorrect conclusions (possibly logical inconsistency). By attribution-inference 13 (http://www.w3.org/TR/prov-constraints/#attribution-inference_text), If oa:serializedBy is subProperty of prov:wasAttributedTo and :ann oa:serializedBy :ag2 then :ann prov:wasGeneratedBy :act2 for some activity :act2 :act2 prov:wasAssociatedWith :ag2 Combined with By attribution-inference 13 (http://www.w3.org/TR/prov-constraints/#attribution-inference_text), If oa:annotatedBy is subProperty of prov:wasAttributedTo and :ann oa:annotatedBy :ag1 then :ann prov:wasGeneratedBy :act1 for some activity :act1 :act1 prov:wasAssociatedWith :ag1 By Constraint 9 (generation-generation-ordering) http://www.w3.org/TR/prov-constraints/#generation-generation-ordering_text If :ann prov:wasGeneratedBy :act1 (generation gen1) :ann prov:wasGeneratedBy :act2 (generation gen2) then gen1 and gen2 occur simultaneously. I don't think this is the intent. To avoid this, I suggest the following changes. PROPOSED: oa:serializedBy is subproperty of property chain inverse(prov:wasDerivedFrom) followed by prov:wasAttributedTo PROPOSED: oa:serializedAt is subproperty of property chain inverse(prov:wasDerivedFrom) followed by prov:wasGeneratedAt If adopted, this requires modifying the figure of appendix A, by adding an prov:wasAttributedTo from annoDocumment1 to agent2. 23. oa:serializedAt I don't understand the explanation "The time at which the agent referenced by oa:serializedBy generated the first serialization of the Annotation, and any subsequent substantially different one. The annotation graph must have changed for this property to be updated, and as such represents the last modified datestamp for the Annotation. This might be used to determine if it should be re-imported into a triplestore when discovered. " Given that we allow more than 1 oa:serializedBy, why do we restrict ourselves to a single oa:serializedAt? In fact, I think it would be not realistic to assume that all serializations are taking place at the same time. (I thought this was acceptaple for oa:annotatedAt, but it is not for oa:serializedAt). 24 Appendix A: Figure: Should we use prov:specializationOf instead of (or in conjunction with) prov:wasDerivedFrom between annoDocument1 and anno? 25 Section 3.3.1 "prov:Agent and foaf:Agent are equivalent classes." They are not, since prov:Agent carries this notion of responsibility that foaf:Agent does not. So, what do is meant here? I think we could safely do the following: PROPOSED: drop this sentence I also suggest: PROPOSED: rewrite "The PROV class is used as FOAF does not define a SoftwareAgent class" to "prov:SoftwareAgent is as FOAF does not define a Software Agent class" 26. Section 3.4 "Although PREVIOUS SYSTEMS have subclassed ..." which systems do you refer to? 27. Section 3.4 With a PROV perspective, the instances of oa:Motivation look like types of prov:Activity. In figure 32 of appendix A, each of these motivations can be seen at the type of activity annotating1. Can we make them all subclass of prov:Activity? This would allow us to refine further the mapping of Appendix A. 28. Section 4: how is this section related to the deliverable robust anchoring? Does it belong to this document? I didn't read sections 4 and 5.