Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
languagenone
titleTurtle
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dc:      <http://purl.org/dc/elements/1.1/> .
 
<http://localhost:3000/virtualcollection/changeme:155>
  rdfs:label    "My Virtual Collection" ;
  rdfs:comment  "These are resources I am gathering together for personal use." ;
  dc:creator    <??? TODOURI DEFINE FOAF PERSON AND USE URI HEREWITH NETID ???> .

NOTE:  Potential alternatives...

...

  • URI for the annotation and annotation body are generated to be unique.
    • Currently shows structure used by Hydra implementation using pid assigned from Hydra UI used to create the annotation which was used for the initial annotation demo at Stanford.  This may not apply going forward.
    • Actual structure of URI is TBA
    • Would this URI be the same as the URL that would allow access to the comment via the web?
  • Original demo at Stanford included a see also property for the annotation.  The see also link was the URL to the visual representation on a webpage.
    • Do we want something similar?
  • These same questions apply to virtual collections.

 

...

Access Thoughts

QUESTIONS:

  • What method is used to protect private Virtual Collections?
    • Option 1:  maintain two triple stores: 1) private, 2) public
    • Option 2:  named graph within a single triplestore
  • What triples, if any, are stored for the following concepts related to access control?
    • Roles  (e.g. site-admin, library-admin, user)
      • only a small set of roles will exist
    • Groups (e.g. shared_read_group, shared_write_group)
      • potential for large number of groups to be created by users
    • Privileges
      • definitions of what users with specific roles can do
  • What of these are application specific and what are needed in triples?

 

Private vs. Public

  • Public Virtual Collection
    • Is discoverable through public search.
    • Any user, logged in or not, can view a public virtual collection.
  • Private Virtual Collection
    • Is NOT discoverable through public search.
    • User must be logged in and be the owner/creator of the virtual collection to view/edit a private virtual collection.

Semi-Private with Shared Access 

  • Allow shared read-only access.  Virtual Collection is not discoverable through public search.
    • Option 1:  Provide a URL that the owner can share with other users.  Anyone using the URL will be able to view the Virtual Collection. 
    • Option 2:  Owner identifies other users who are allowed to view the Virtual Collection

Collaboration

  • Allow share write access
    • Option 1: Owner identifies other users who are allowed to edit the Virtual Collection.

NOTE: This doesn't really come into play until Use Case 1.2, but I want to think about the other access issues with this in mind.