Two options, listed below, for annotating parts of resources were considered for the Open Annotation Data Model. We decided on the more expressive but more verbose second option for a variety of reasons, that this page explains in more detail than in the specification.<\/p>\n
Option (1) Fragment URI as target<\/b><\/p>\n Option (2) Identity as target, description as a Selector<\/b><\/p>\n To decompress the reasoning in the specification<\/a>:<\/p>\n Thus, there is a need for a Selector that describes the segment of a After all of that, if you’re still not convinced, then it’s only a recommendation to use this approach. If you feel that (This page is taken from: http:\/\/lists.w3.org\/Archives\/Public\/public-openannotation\/2012Oct\/0008.html<\/a>)<\/p>\n","protected":false},"excerpt":{"rendered":" Two options, listed below, for annotating parts of resources were considered for the Open Annotation Data Model. We decided on the more expressive but more verbose second option for a variety of reasons, that this page explains in more detail … Continue reading
\n\r\n_:anno a oa:Annotation ;\r\n oa:hasTarget <http:\/\/www.example.com\/example.ogv#t=10,20> ;\r\n oa:hasBody <http:\/\/www.example.org\/comment1> .\r\n<\/pre>\n
\n
\n\r\n_:anno a oa:Annotation ;\r\n oa:hasTarget <SpecificTarget1> ;\r\n oa:hasBody <http:\/\/www.example.org\/comment1> .\r\n\r\n<SpecificTarget1> a oa:SpecificResource ;\r\n oa:hasSelector <FragmentSelector1> ;\r\n oa:hasSource <http:\/\/www.example.com\/example.ogv> .\r\n\r\n<FragmentSelector1> a oa:FragmentSelector ;\r\n rdf:value \"t=10,20\" .\r\n<\/pre>\n
\n\n
\nthe first model. Remember that URIs are opaque, non-decomposable strings. Regardless of whether that
\nstring may include human readable semantics or not, you can’t discover
\nannotations of form (1) with regular SPARQL constructions and you can discover them in form (2) by
\nquerying the object of oa:hasSource. It is possible to discover them using regular expressions in SPARQL. <\/p>\n
\nwith States. If you need to refer to example.ogv at a particular
\npoint in time then you need a State which cannot be attached to the
\nFragment URI, as that would break the global scope of statements in
\nRDF. In other words, you would be saying that for all uses of that
\ntime range within the video, it was always based on the video resource
\nas it was at a particular point in time (say at 2011-05-20), which
\nwould prevent other annotations from having a different point in time
\nfor that same time segment within the video.<\/p>\n
\nfor the segment, but also a description of how to resolve that segment
\ngiven a (particular) representation of the resource. This has several
\nissues:<\/p>\n\n
\ndifferent communities.<\/p>\n
\nPlain text fragments work only for text\/plain
\nresources, and no other, for example. Thus the identity of the segment is tied to a specific representation in a specific format<\/p>\n
\ndifferent things within the same resource. She gives the example of
\nan SVG document with embedded RDF in Appendix B<\/a>.
\nSo we consider it safer to create a new node in the graph to provide
\nidentity, and a separate node to provide the description. This
\nsafety, expressiveness and consistency comes at the expense of some
\nextra bytes, but that’s RDF for you.\n<\/ul>\n
\ndrive the Open Annotation specification. Non rectangular sections of
\nimages are very important to be able to identify and describe,
\nincluding simple circles as well as arbitrary paths. The worst case
\nis annotating a diagonal road in a map from top left to bottom right
\nof the image, where a rectangular box would encompass the whole
\nimage’s content. Thus we need some other way to implement this, which
\nresults in form (2)<\/p>\n
\nhope to. If you wanted to annotate a selection of text within a MS
\nWord document, you would need Microsoft to register a fragment
\ndescription for .doc and .docx. Given that this is a useful sort of
\nthing to do, and it can’t be done with fragment URIs, we need a
\nselector concept as in form (2)<\/p>\n
\nAs soon as anyone needed something slightly richer or more
\nexpressive … like a circular area rather than rectangular … then
\nwe would be back in the situation where we needed a selector again.\n<\/ul>\n
\nresource separately from its identity. Given that this is required,
\nwe felt it most consistent to always use a Selector, but to import the
\nfragment description semantics into it. This solves all of the issues
\nabove at the expense of being somewhat more verbose.<\/p>\n\n
\nresource, without any segment information<\/p>\n
\nfor the representation. The failure to consider the dynamic nature of
\nweb resources has been the downfall of many annotation systems in the
\npast, and we fully intend to learn from their mistakes.<\/p>\n
\n There is no confusion about what the Specific Resource identifies as
\nit does not also try to describe it.<\/p>\n
\nconsistent with a single model<\/p>\n
\nblessing of the IANA\/IETF registries<\/p>\n
\nneed to implement both of or risk splitting their user base<\/p>\n
\nre-inventing those. We simply split the fragment away from the URI of
\nthe full resource to gain the benefits above.<\/p>\n
\nthat the single selector model was the better approach\n<\/ul>\n
\nsome additional bytes in an already extremely verbose format is too
\nhigh a cost for interoperability, expressiveness, consistency and the
\nunderstandability of your annotations, then it is not forbidden to
\nannotate a fragment URI directly. We hope, of course, that you’re
\nconvinced otherwise by the arguments above \ud83d\ude42<\/p>\n