![]() ![]() access_status: determines whether an annotation is private, shared or public.can_edit: list of users who can see and edit an annotation.can_see: list of users who can see but not edit an annotation.The annotation protocol can deal with authorization through URL query parameters. The W3C working group for Web Annotations suggests to use the audience property for any group-related aspects and that authorization and authentication are not responsibilities of the annotation data model (as discussed in this issue on GitHub: How do we model “groups” in the Annotation Model).Īuthentication is dealt with by the annotation server. There is also currently no provision in Alexandria for user-based access limitations, or grouping of users.] Capturing groups and permissions in annotations This can be an alternative or an additional way of dealing with edit/delete. ![]() DELETED annotations are hidden by default, but can still be retrieved. Also, sending a DELETE to an annotation sets the state of that annotation to DELETED. When referring to the annotation by URI, it always refers to the latest version of the annotation, but all versions of the annotation can be retrieved by adding /ver/ + the version number to the annotation URI. [BB: In Alexandria, there is no “editing” of an annotation as such, when you PUT to an existing annotation, this creates a new annotation that replaces the existing annotation, and increases the “version” number. Another way is to not allow changing/removing annotations that are targets of other annotations. One way of dealing with this is to add a notification to annotations that target a changed/deleted annotation. If an annotation is the target of a later annotation, it cannot be changed or removed without consequences. There are some issues regarding changing or deleting annotations. The client can indicate edit permissions through e.g. The server should check with each PUT request whether the user has edit permissions. creator, created) should not be changeable. The properties relation to the creation of the annotation (e.g. To avoid overly complex permission models, there should only be a single set of properties that are allowed to be changed. Changes are timestamped via the modified property. writing: the permission to make changes to an annotation, including deleting it.The responsibility lies with the server to return only annotations to a user who has read permissions. read: the permission to see/view/read an annotation.The owner of an annotation can have (What?) The server may return public annotations for requests without an authenticated user. public: the public represents any user.Users may want to share an annotation with multiple users and/or multi-user groups, so this can be a list of groups (single-user and multi-user groups). Additional groups can be made that can have multiple members. group: the group(s) who have access to the annotation.The owner can only be a single entity, e.g. By default, this is the creator of the annotation, but it should be possible to transfer ownership to other users or groups of users. owner: the user who is the owner of the annotation.R4: owners should be able to change operation permissions per level and per group.R2: the operation types reading and writing should have their own permissions.R1: there should be permission levels for owner, group and public.This results in the following list of requirements: The execute operation in UNIX has no meaningful correspondence in the annotation domain, so it can be discarded. This can also be based on the UNIX model for read/write/execute permissions. ![]() seeing (reading) and changing or removing (writing). Given that a user can create, retrieve, edit, and remove annotations, it makes sense to have separate permissions for different operations, e.g. The most basic permission is being able to read/see/view an annotation. It may also be desirable to transfer full permissions to a group of users. Transferring permissionsĮach annotation must have see/edit/delete permissions for at least one user (typically the creator), but there may be a need to transfer permissions to another user. A flexible solution for dealing with groups is the UNIX model, where users represent their own groups, but additional groups can be made to which multiple users can belong. scholarly-web-annotation-client Javascript annotation client for RDFa enriched web resources View on GitHubĪnnotation Access Permissions Permission Requirements Levels of permissionsįrom discussions with potential users it is clear there is a need to have different levels of permissions, with the default being private, that is, only the creator of an annotation can see/edit/delete the annotation. ![]() Annotation Access Permissions | scholarly-web-annotation-client Skip to the content. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |