User Type
here is a description of different user types and privileges for discussion. this is a
priority to resolve as it affects the datamodel, class definitions and
interface.
browser:
- anonymous
- no login
- no workspace, favorites
- access to all viewable content
- no contribution, editing privileges
researcher:
- requires automatic registration (no approval required)
- same access to content as browser
- login to access favorites, profile, add content to favorites
contributor:
- researcher that has been accepted to this level (who accepts them?)
- login to access all workspace functionality
- can create new project,unit,resource
- can manage own content (ie: edit, make viewable, lock, delete)
- can attach any resource to own units, any unit to own projects
- can associate/unassociate contributors with project/unit
- QUESTIONS:
1) to who does a contributor allow edit privileges to their content -
should this be any existing researcher or contributor?
2) if researchers, do they have the ability to associate/unassociate
resources->units, unit->project?
3) if researchers, can they add resources?
4) are all contributors associated with given content the same, or
does the original creator have special status - ie: only they can add/
remove contributors to their content and set privileges?
administrator:
- login to access all workspace functionality
- all lower level management (ie do anything) done via phpmyadmin
interface
- one or more administrators allowed
This section only | References/ Recommended Reading (0)
user profile text fields
regarding user profile text fields: name - should be 2 fields: givename,surname (its good to split these up for sorting) email - definitely needs to be in its own field as its their login title - i would drop: leave this up to them to put in their bio if they choose postal address - i could see city/town & country might be useful, might be too invasive to ask for complete address hyper links - if we want multiple it would be good to have a set limit to keep the data model from getting more complicated
This section only | References/ Recommended Reading (0)
Revised Data Model
the data model has evolved slightly.
changes:
- added 'resource:parentid' to capture whether resource is original or
modified version
- added 'contributor:sponsorid' to track number of new contributors
registered by an existing contributor
- added 'log:contenttype' to capture whether content is object,
resource, subject or contributor
- reversed one-to-many direction of the contributor-subject relation
(original was a mistake)
- hilighted 'log' to denote it as entity rather than relation
explanations:
- possible 'action' data in log:
create,modify,copy,delete,view,login,logout
questions:
- should we allow unit content to be exposed in project view on a
per-unit basis? (this question previously noted)
- should we allow resource to be displayed inline in unit view on a
per-resource basis (where possible, given the type of resource, ie:
image, URL, etc)?
- should we allow a unit to be tied to a project as EITHER original
(only original creator can modify, therefore it might change/disappear)
OR copy (you gain control of further mods on it)?
notes:
- i'm thinking about collapsing 'resource' into 'object' and just
making it another type. if you have any thoughts about this, please
bring them up at our next meeting.
revised data model attached (please disregard previous version).
This section only | References/ Recommended Reading (0)
dlp-meeting_050915
dlp-meeting_050915
----------------------------------
Thursday 11-12:30, Sep15/05
w/ Tom,Thom,Trebor,Chris
changes of spec:
- we don't write subject definitions
- user can't define related subjects
-- only based on description field content
-- subject relationships updated in database after every description
update
-- optionally (user choice) expose related projects, modules, resources
in menu (changing redraws page)
-- expose related project,module,resource in project,module,resource
views
- no related subject list, only in description field
- eg: "foucault, surveillance" subjects -> search algorithm =
"foucault+surveillance", "foucault", "surveillance", "children of
foucault+surveillance", "children of foucault", "children of
surveillance"
dlp-meeting_050920.txt
----------------------------------
Tuesday 11-12:30, Sep20/05
w/ Tom,Thom,Trebor,Chris
terminology:
- term 'module' changed to 'unit'
interface:
- page view for contributor added
content modification:
- projects can be modified or deleted by owner
- units from other contributors are copies with parent unit ID recorded
- can resources be modified?
-- maybe any mod should be a copy
-- if so, we need to reference parent resource ID
- can resources be deleted?
-- definitely can be deleted by sysadmin
-- maybe by owner -> need to decide
This section only | References/ Recommended Reading (0)
DLP Mile Stones Fall 05
here is a proposed list of project milestones. send your additions/revisions to all so we can finalize this in the next week or 2:
September 1:
- database structure finalized & set up
- backend code libraries in place
- prototype interface online
- prototype scripts running
- project identity finalized (ie: name, logo, visual style)
- background page content finalized
- begin prototype testing with DDD course
October 1:
- interface & script revisions done based on prototype testing
- begin testing custom interfaces
- begin prototype testing with select user group
November 1:
- tool distribution documents ready
- final revisions ready for release
- invitiation for wider participation
- official release mid-November
This section only | References/ Recommended Reading (0)
project interface mockups
This section only | References/ Recommended Reading (0)
development notes 0217
subject relationships
---------------------------
- subject relationships of resource,module,subject all based on subject occurence in description field
- during input phase give contributor feedback on what subjects found in description in order for them to be able to modify description and consequent subject linking
This section only | References/ Recommended Reading (0)
development notes 0210
copyright license
----------------------
choose from list for project, module, resource
- none is an option
description for resource, module
----------------------
either use contributor's or make custom when linking to project, module
object states
----------------------
possible access states for different objects:
- project: private,public (private->public 1 way street)
- module: private,public,publish (private->public 1 way street)
- resource: metadata->public, media->publish
changes to database
----------------------
contributor table: c_description -> c_bio
license table: l_id, l_name (256 char), l_iconfile, l_url
project, module description
----------------------
auto linking of embedded subject words
subject association
----------------------
resource: contributor associates with subjects
project, module: automatically associated based on update of description field
- all linked resource associations aggregated
- subject associations ranked by contributor
This section only | References/ Recommended Reading (0)
dlp-ResourceDescriptors
dlp-ResourceDescriptors
--------------------------------
The following resource descriptors are based on the Dublin Core metadata element set. They generally (unless otherwise noted) correspond to resource fields in the DLP database and would be externally accessible via XML for interoperability with other similar projects (ie: MIT, Harvard, Rice, etc):
Title
- r_title text field (128 char max)
- output eg: "Thoughts on 'Database as a Symbolic Form'"
Creator
r_creator text field (64 char max)
- output eg: "Trebor Scholz"
Subject
- this field automatically generated
- comma separated, alphabetically ordered list of all subject names associated with resource
- output eg: "Database, Cinema, Lev Manovich, Media Theory"
Description
- r_description text field (512 char max)
- output eg: "A review of the Lev Manovich paper, Database as a Symbolic Form. Provides a synopsis and critique of its central theme of the relationship between database and narrative forms."
Publisher
- this field automatically generated
- always name of this project
- output eg: "Distributed Learning Project"
Contributor
- this field automatically generated
- associates r_contributorid => c_givenname + c_familyname
- output eg: "Tom Leonhardt"
Date
- this field automatically generated
- describes the last modified date
- always in the form "YYYY-MM-DD"
- output eg: "2005-01-30"
Type
- r_type text field
- chosen from list: Collection, Dataset, Event, Image, InteractiveResource, MovingImage, PhysicalObject, Service, Software, Sound, StillImage(?), Text
- see: http://dublincore.org/documents/dcmi-type-vocabulary/
- output eg: "Text"
Format
- r_format text field
- chosen from list: gif, html, jpeg, mpeg, pdf, png, quicktime, rtf, text, xml
- see: http://www.iana.org/assignments/media-types/
- output eg: "pdf"
Identifier
- r_identifier text field (256 char max)
- r_identifiertype text field
- chosen from list: URL, ISBN, none
- output eg: "URL, http://www.molodiez.org/dlp/page/home.php"
Source
- not used
Language
- 3 character language code
- default "eng", others allowed, typed in by contributor
- for code list see: http://www.loc.gov/standards/iso639-2/langcodes.html
- output eg: "eng"
Relation
- not used
Coverage
- not used
Rights
- chosen from list: various CC licenses (?)
- this field generated by associating r_licenseid with l_url
- url to online resource which specifies nature of particular rights
- output eg: http://creativecommons.org/licenses/by/2.0/
This section only | References/ Recommended Reading (0)
Meeting 27/05
my notes regarding meeting with Thomas Jan 27/05:
- in first part of meeting i described and clarified main structural
concepts:
subject,resource,module,project
- discussed strategies for creating content
-- contributor should be able to either link existing resources or
create new ones when creating/modifying module/project
- discussed the relative complexity of project and module
-- module could be used to group together images into a gallery
-- modules should be very stand-alone and self contained
-- modules within modules allowed?
-- Thomas suggested that the idea of content repository and course
publishing should be thought of as separate ideas:
project should not be seen as a course publishing method because
courses involve other issues such as class lists, timetables, etc.
- discussed how to describe resources
-- Thomas suggested looking at Dublin Core (I had previously, but will
look more closely)
-- DC is a standard common in library science
-- see attached DC element list, DLP resource descriptors
- todo:
-- Thomas suggested priority for interface mockup is module creation one
- next meeting: Thursday, Feb 3, 10:45am
