Entifying Sakai Tools or RESTful Access to Tool Content

[Peter Knoop]

One of the cornerstones of the Content Authoring idea is that tool
content or entities (or resources or items or parts or fragments or ...)
should be URL addressable, so that they can be easily browsed and
embedded in a Sakai-authored page.  Currently many Sakai tools only
allow access to their content from a single, top-level URL, and the user
has to manually navigate to specific views or items within the tool.  In
some conversations the work that needs to be done to enable such direct
access to tool content has been called "entification" or "entifying" a
tool, but in more standard web 2.0-speak, we are referring to REST
(REpresentational State Transfer), or, in other words, talking about
enabling RESTful access to tool content.

So what "things" should be accessible in such a manner?  Mathieu Plourde
put together an excellent initial list prior to the Dearborn Authoring
Summit this past September:

 http://confluence.sakaiproject.org/confluence/x/kQF1Ag

We need your help in reviewing this list and identifying other "things"
in Sakai tools that may have been overlooked.  We're also looking for
input on which "things" you think are the most important in order to
help prioritize "entification" of the existing Sakai tools.  (And, of
course, anyone who can help with actual entification by contributing
patches or working directly with the existing project teams, then please
let me know!)  Please provide your input by next Friday, 19 December
2008.

So please add a comment to the above page with your thoughts and
suggestions.  Or, if you are having difficulty accessing the Confluence
page, then let me know and I'll send you a PDF export of the current
page and comments, and you can provide your input to me by email.

Thanks!

-peter
Sakai Project Coordinator
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[Clay Fenlason-3]

One thing which I've been assuming, but which a review of the
Confluence page suggests might have been presumptuous, is that we're
considering dynamic as well as static entities.  That is to say, I
think of "dynamic" entities as abstractions colored in with the
appropriate detail in context.  As an example, I might take two
assignments entities:  the assignment description, and the assignment
submission.  The description will often be static - it will tend to be
the same thing for everyone.  But I can also imagine plugging a widget
into my page which is labeled "My Submission," with the aim of
allowing each student viewer of that page a widget displaying their
own particular submission to the assignment.

This is a little different from treating entities as resources.  It is
more like treating them as resource containers that will be populated
in context.  I think this complicates the design problem.  Is it
otherwise inadvisable?

~Clay

On Thu, Dec 11, 2008 at 5:49 PM, Knoop, Peter <knoop@...> wrote:

> One of the cornerstones of the Content Authoring idea is that tool
> content or entities (or resources or items or parts or fragments or ...)
> should be URL addressable, so that they can be easily browsed and
> embedded in a Sakai-authored page. Currently many Sakai tools only
> allow access to their content from a single, top-level URL, and the user
> has to manually navigate to specific views or items within the tool. In
> some conversations the work that needs to be done to enable such direct
> access to tool content has been called "entification" or "entifying" a
> tool, but in more standard web 2.0-speak, we are referring to REST
> (REpresentational State Transfer), or, in other words, talking about
> enabling RESTful access to tool content.
>
> So what "things" should be accessible in such a manner? Mathieu Plourde
> put together an excellent initial list prior to the Dearborn Authoring
> Summit this past September:
>
> http://confluence.sakaiproject.org/confluence/x/kQF1Ag
>
> We need your help in reviewing this list and identifying other "things"
> in Sakai tools that may have been overlooked. We're also looking for
> input on which "things" you think are the most important in order to
> help prioritize "entification" of the existing Sakai tools. (And, of
> course, anyone who can help with actual entification by contributing
> patches or working directly with the existing project teams, then please
> let me know!) Please provide your input by next Friday, 19 December
> 2008.
>
> So please add a comment to the above page with your thoughts and
> suggestions. Or, if you are having difficulty accessing the Confluence
> page, then let me know and I'll send you a PDF export of the current
> page and comments, and you can provide your input to me by email.
>
> Thanks!
>
> -peter
> Sakai Project Coordinator
> ________________________________
> This automatic notification message was sent by Sakai Collab
> (https://collab.sakaiproject.org//portal) from the Management site.
> You can modify how you receive notifications at My Workspace > Preferences.
>

--
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
[phone]
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[jrnorman]

Assignment Submission is on the page as an entity. I think the only  
real issue is whether "resources" is a good name for student submitted  
work. Arguably, it is a resource from the students perspective  
(something they *may* want to include in a portfolio), but perhaps not  
from an instructor's perspective. For now, I'll put down a placeholder  
- we are talking about "resources and submissions" - but I imagine we  
might find a better description as we work through the tools and find  
more examples...

Are you suggesting that student responses to quiz and test should be  
accessible the same way..?

John

On 12 Dec 2008, at 00:02, Clay Fenlason wrote:

> One thing which I've been assuming, but which a review of the
> Confluence page suggests might have been presumptuous, is that we're
> considering dynamic as well as static entities. That is to say, I
> think of "dynamic" entities as abstractions colored in with the
> appropriate detail in context. As an example, I might take two
> assignments entities: the assignment description, and the assignment
> submission. The description will often be static - it will tend to be
> the same thing for everyone. But I can also imagine plugging a widget
> into my page which is labeled "My Submission," with the aim of
> allowing each student viewer of that page a widget displaying their
> own particular submission to the assignment.
>
> This is a little different from treating entities as resources. It is
> more like treating them as resource containers that will be populated
> in context. I think this complicates the design problem. Is it
> otherwise inadvisable?
>
> ~Clay

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[dlhaines]

For authorization reasons Sakai will need to know something about who  
is making a request and that information can be used to make a request  
more specific. One approach to having generic URIs would be to use a  
set of "resolver" URIs that can be used to redirect from a seemingly  
generic request to a specific one.

For example an implementation might translate "https://localhost/sakai/rest/myworkspace 
" to "https://localhost/sakai/rest/myworkspace?user=claystheman" and  
then translate that to the specific site "https://localhost/sakai/rest/site/8909w8e09r8098w0e9r8098 
".  The value of user would be filled in the context.  It might be  
passed explicitly from session information, or obsurced in request  
headers, or passed in some other clever way from the application state.

(Those are utterly imaginary URIs.  I'm not suggesting that particular  
format.)

- Dave

David Haines
CTools Developer
Digital Media Commons
University of Michigan
dlhaines@...




On Dec 11, 2008, at 7:02 PM, Clay Fenlason wrote:

> One thing which I've been assuming, but which a review of the
> Confluence page suggests might have been presumptuous, is that we're
> considering dynamic as well as static entities. That is to say, I
> think of "dynamic" entities as abstractions colored in with the
> appropriate detail in context. As an example, I might take two
> assignments entities: the assignment description, and the assignment
> submission. The description will often be static - it will tend to be
> the same thing for everyone. But I can also imagine plugging a widget
> into my page which is labeled "My Submission," with the aim of
> allowing each student viewer of that page a widget displaying their
> own particular submission to the assignment.
>
> This is a little different from treating entities as resources. It is
> more like treating them as resource containers that will be populated
> in context. I think this complicates the design problem. Is it
> otherwise inadvisable?
>
> ~Clay
>
> On Thu, Dec 11, 2008 at 5:49 PM, Knoop, Peter <knoop@...> wrote:
> > One of the cornerstones of the Content Authoring idea is that tool
> > content or entities (or resources or items or parts or fragments  
> or ...)
> > should be URL addressable, so that they can be easily browsed and
> > embedded in a Sakai-authored page. Currently many Sakai tools only
> > allow access to their content from a single, top-level URL, and  
> the user
> > has to manually navigate to specific views or items within the  
> tool. In
> > some conversations the work that needs to be done to enable such  
> direct
> > access to tool content has been called "entification" or  
> "entifying" a
> > tool, but in more standard web 2.0-speak, we are referring to REST
> > (REpresentational State Transfer), or, in other words, talking about
> > enabling RESTful access to tool content.
> >
> > So what "things" should be accessible in such a manner? Mathieu  
> Plourde
> > put together an excellent initial list prior to the Dearborn  
> Authoring
> > Summit this past September:
> >
> > http://confluence.sakaiproject.org/confluence/x/kQF1Ag
> >
> > We need your help in reviewing this list and identifying other  
> "things"
> > in Sakai tools that may have been overlooked. We're also looking for
> > input on which "things" you think are the most important in order to
> > help prioritize "entification" of the existing Sakai tools. (And, of
> > course, anyone who can help with actual entification by contributing
> > patches or working directly with the existing project teams, then  
> please
> > let me know!) Please provide your input by next Friday, 19 December
> > 2008.
> >
> > So please add a comment to the above page with your thoughts and
> > suggestions. Or, if you are having difficulty accessing the  
> Confluence
> > page, then let me know and I'll send you a PDF export of the current
> > page and comments, and you can provide your input to me by email.
> >
> > Thanks!
> >
> > -peter
> > Sakai Project Coordinator
> > ________________________________
> > This automatic notification message was sent by Sakai Collab
> > (https://collab.sakaiproject.org//portal) from the Management site.
> > You can modify how you receive notifications at My Workspace >  
> Preferences.
> >
>
>
>
> --
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> [phone]
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the Management site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.