Ordering of Constraints
Robert Sanderson
We have updated the discussion document concerning the ordering or
precedence of Constraints to explain a new alternative, which we feel
covers all of the expressed requirements without adding unnecessary
complexity in the simple cases.
We would greatly appreciate any feedback on this :)
The new section of the discussion document is:
http://www.openannotation.org/spec/beta/precedence.html#DM_Offset
And builds upon ideas from the previous options.
Many thanks,
Rob Sanderson
Bruce D'Arcus
> We have updated the discussion document concerning the ordering or
> precedence of Constraints to explain a new alternative, which we feel
> covers all of the expressed requirements without adding unnecessary
> complexity in the simple cases.
> We would greatly appreciate any feedback on this :)
Isn't Bag effectively deprecated in RDF usage?
Bruce
Robert Sanderson
Yes, that's definitely an issue, however we don't know what any
replacement construction will be.
I'll clarify in the document that this uses the current RDF
specification, but we realize it will need to be modified should that
specification change.
Other than that, does it seem to fit any ordering requirements that
you have come across?
Thanks!
Rob
Bruce D'Arcus
> Yes, that's definitely an issue, however we don't know what any
> replacement construction will be.
> I'll clarify in the document that this uses the current RDF
> specification, but we realize it will need to be modified should that
> specification change.
>
> Other than that, does it seem to fit any ordering requirements that
> you have come across?
To be honest, I can't think of a use case where order would matter.
But you mention there are some. Do you have a link?
Bruce
Brian Hoffman
I am writing to see if anyone else has considered whether or not to use constraints in cases where a resource supports resolvable URIs that represent fragments.
I am thinking specifically of a case of a web resource representing either a photograph or a page of a book, though I think the issue is a general one.
If a user wants to annotate a sub-region of the resource, this might result in an OAC annotation with a target representing the (whole) resource and a constraint representing a geometry to be used to differentiate part of the resource from the rest of it. But this 'use' seems quite abstract, and short of something like a browser plugin or a protocol for retrieving and rendering constraints, it is hard to imagine how the selected area will be presented to a user interested in seeing the target of a fragment-oriented annotation.
On the other hand, if the target resource is built in such a way that it supports resolvable URIs that represent arbitrary parts of itself, it seems like constraints could be eschewed in favor of targeting the resource part directly. In this case, I am thinking of a web resource representing a photograph or book page and capable of accepting coordinates as part of an HTTP request, which coordinates would then be highlighted or outlined for the user. (There may be a related issue to discuss of what else it could mean to represent a fragment.)
Has anyone else working with annotation implementations dealt with this issue? Is it a bad idea to, when one is both publishing web resources and providing an annotation service, to shift the responsibility for constraining to the resource and away from the annotation service whenever possible? Should constraints be seen as a fallback for cases where the resource (or web protocols) are not capable of furnishing a resolvable URI to represent the intended fragment?
Any thoughts or opinions would be welcome.
Brian
Robert Sanderson
There are definitely use cases for both the URI and the Constraint approach.
The URI approach is much simpler to understand, for example with media
fragments for images, audio and video, as the one URI both identifies
the region of interest uniquely, and describes to a consuming
application how to extract it.
However the use is limited to rectangular regions of images rather
than arbitrary shapes. Even a circle, which requires less information
than a rectangle (x y and radius, vs x y width and height), isn't
possible with media fragments. Also, there are many *many* types of
resource online, and fragments only cover a very small number of them.
If a resource supported arbitrary segmentation, then those URIs could
definitely be annotated.
The things to consider:
* How would a third party annotation client know how to generate the
URIs for the segments?
* How would a different third party annotation client know how to
render the segment URIs?
+ While following its user's preferences, such as highlights
should always be yellow
As to the point that a browser would need assistance in rendering,
this is also surely true for interpreting the annotations at all
before getting to the constraint. As long as the constraint is
implementable in javascript, it could be handled at the page level or
via very simple browser add-ons such as bookmarklets. In my
experience this has covered 99% of the different types of constraint
and URI fragment I've wanted.
As a possible hybrid solution, you could provide a service that
resolved a standards based constraint into a resolvable URI.
Annotations could then use this URI as the ConstrainedTarget, allowing
clients the option of dereferencing the URI directly, or using
internal capabilities to render the Constraint.
Hope that helps, or at least provides some food for discussion :)
Rob