Content representations for Box

[Paul Everitt]

The goal is to put all the content about a community into a Box parent folder with the name of the community, then subfolders for each tool. We then create content in KARL for each resource in the tool.

Think about the most-feasible representation of a Blog Entry (with Attachment), Blog Entry, etc. Even Folder and File objects have some extra data.

In fact, the community itself has some data: members, tags. How feasible is it to represent various information in a community?

[Chris Rossi (chris-archimedeanco)]

Hi Paul,

I've gone ahead and committed the first little bit, in progress, so you can see the basic strategy and provide critique and/or course corrections sooner than later.

There is a new console script, bin/archive <community_name> <folder> that dumps community content to the local filesystem. It does this by first constructing an in memory representation and then realizing that representation to the filesystem. The code to realize the representation to the filesystem is only 7 lines, so the idea that moving from the filesystem realization to the Box realization should be trivially easy. In the meantime, the work in progress is easy to see without having to fool with Box.

So far, it creates an index page for the community and archives the community's blog. I'll be moving on to the other tools shortly, using the same basic strategy.

[Chris Rossi (chris-archimedeanco)]

Do we need calendar?

[Paul Everitt (paul-agendaless)]

I think we do need calendar, *but*...given Nat's time constraints, I think we could implement that after he goes away for holidays. Perhaps we should get to the end on FILES and maybe BLOG, working out other parts of the workflow.

--Paul

> On Dec 8, 2014, at 1:12 PM, Chris Rossi <email address hidden> wrote:
>
> Do we need calendar?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1398072
>
> Title:
> Content representations for Box
>
> Status in OSF KARL4:
> In Progress
>
> Bug description:
> The goal is to put all the content about a community into a Box parent
> folder with the name of the community, then subfolders for each tool.
> We then create content in KARL for each resource in the tool.
>
> Think about the most-feasible representation of a Blog Entry (with
> Attachment), Blog Entry, etc. Even Folder and File objects have some
> extra data.
>
> In fact, the community itself has some data: members, tags. How
> feasible is it to represent various information in a community?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1398072/+subscriptions

[Paul Everitt (paul-agendaless)]

I have to do an update to get new packing code to gocept. After that I'll review what you did below.

--Paul

> On Dec 8, 2014, at 11:32 AM, Chris Rossi <email address hidden> wrote:
>
> Hi Paul,
>
> I've gone ahead and committed the first little bit, in progress, so you
> can see the basic strategy and provide critique and/or course
> corrections sooner than later.
>
> There is a new console script, bin/archive <community_name> <folder>
> that dumps community content to the local filesystem. It does this by
> first constructing an in memory representation and then realizing that
> representation to the filesystem. The code to realize the
> representation to the filesystem is only 7 lines, so the idea that
> moving from the filesystem realization to the Box realization should be
> trivially easy. In the meantime, the work in progress is easy to see
> without having to fool with Box.
>
> So far, it creates an index page for the community and archives the
> community's blog. I'll be moving on to the other tools shortly, using
> the same basic strategy.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1398072
>
> Title:
> Content representations for Box
>
> Status in OSF KARL4:
> In Progress
>
> Bug description:
> The goal is to put all the content about a community into a Box parent
> folder with the name of the community, then subfolders for each tool.
> We then create content in KARL for each resource in the tool.
>
> Think about the most-feasible representation of a Blog Entry (with
> Attachment), Blog Entry, etc. Even Folder and File objects have some
> extra data.
>
> In fact, the community itself has some data: members, tags. How
> feasible is it to represent various information in a community?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1398072/+subscriptions

[Chris Rossi (chris-archimedeanco)]

Ok, files and blog are both implemented. Next step would be Wiki, or stop and think about html styling a little bit. Possibly we could have some parallelism if you want to come in behind me and craft some minimal css to make the output a hair more comprehensible.

[Paul Everitt (paul-agendaless)]

Console script ran as expected.

I think we should bail on the quality of the output and move on to the workflow of archiving stuff. I have a bunch of notes, and a draft UI. But I probably should write it up for you to review before I do anything, right?

--Paul

> On Dec 8, 2014, at 2:50 PM, Chris Rossi <email address hidden> wrote:
>
> Ok, files and blog are both implemented. Next step would be Wiki, or
> stop and think about html styling a little bit. Possibly we could have
> some parallelism if you want to come in behind me and craft some minimal
> css to make the output a hair more comprehensible.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1398072
>
> Title:
> Content representations for Box
>
> Status in OSF KARL4:
> In Progress
>
> Bug description:
> The goal is to put all the content about a community into a Box parent
> folder with the name of the community, then subfolders for each tool.
> We then create content in KARL for each resource in the tool.
>
> Think about the most-feasible representation of a Blog Entry (with
> Attachment), Blog Entry, etc. Even Folder and File objects have some
> extra data.
>
> In fact, the community itself has some data: members, tags. How
> feasible is it to represent various information in a community?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1398072/+subscriptions

[Chris Rossi (chris-archimedeanco)]

Ok, sounds good.

On Mon, Dec 8, 2014 at 3:19 PM, Paul Everitt <email address hidden> wrote:

> Console script ran as expected.
>
> I think we should bail on the quality of the output and move on to the
> workflow of archiving stuff. I have a bunch of notes, and a draft UI.
> But I probably should write it up for you to review before I do
> anything, right?
>
> --Paul
>
> > On Dec 8, 2014, at 2:50 PM, Chris Rossi <email address hidden> wrote:
> >
> > Ok, files and blog are both implemented. Next step would be Wiki, or
> > stop and think about html styling a little bit. Possibly we could have
> > some parallelism if you want to come in behind me and craft some minimal
> > css to make the output a hair more comprehensible.
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/1398072
> >
> > Title:
> > Content representations for Box
> >
> > Status in OSF KARL4:
> > In Progress
> >
> > Bug description:
> > The goal is to put all the content about a community into a Box parent
> > folder with the name of the community, then subfolders for each tool.
> > We then create content in KARL for each resource in the tool.
> >
> > Think about the most-feasible representation of a Blog Entry (with
> > Attachment), Blog Entry, etc. Even Folder and File objects have some
> > extra data.
> >
> > In fact, the community itself has some data: members, tags. How
> > feasible is it to represent various information in a community?
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/karl4/+bug/1398072/+subscriptions
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1398072
>
> Title:
> Content representations for Box
>
> Status in OSF KARL4:
> In Progress
>
> Bug description:
> The goal is to put all the content about a community into a Box parent
> folder with the name of the community, then subfolders for each tool.
> We then create content in KARL for each resource in the tool.
>
> Think about the most-feasible representation of a Blog Entry (with
> Attachment), Blog Entry, etc. Even Folder and File objects have some
> extra data.
>
> In fact, the community itself has some data: members, tags. How
> feasible is it to represent various information in a community?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1398072/+subscriptions
>

[Paul Everitt (paul-agendaless)]

Chris, what's the status on this? I think it might be done, or is there a niggle left?

[Chris Rossi (chris-archimedeanco)]

Calendar and Wiki are not done. I think we at least need to do Wiki. I'll do that now. I'll look for guidance on whether we need calendar.

[Paul Everitt (paul-agendaless)]

As triage, let's talk about the simplest possible representation of calendar and then, how much work it is.

How hard would this be:

- For each calendar event, a directory, containing...

- An HTML file with the bare information of the calendar event (no visualization)

- Files for any attachments

--Paul

> On Jan 8, 2015, at 10:40 AM, Chris Rossi <email address hidden> wrote:
>
> Calendar and Wiki are not done. I think we at least need to do Wiki.
> I'll do that now. I'll look for guidance on whether we need calendar.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1398072
>
> Title:
> Content representations for Box
>
> Status in OSF KARL4:
> In Progress
>
> Bug description:
> The goal is to put all the content about a community into a Box parent
> folder with the name of the community, then subfolders for each tool.
> We then create content in KARL for each resource in the tool.
>
> Think about the most-feasible representation of a Blog Entry (with
> Attachment), Blog Entry, etc. Even Folder and File objects have some
> extra data.
>
> In fact, the community itself has some data: members, tags. How
> feasible is it to represent various information in a community?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1398072/+subscriptions

[Chris Rossi (chris-archimedeanco)]

Actually, how about one directory, with one html file with all of the events, attachments all in the same folder?

[Paul Everitt (paul-agendaless)]

Fine by me.

> On Jan 8, 2015, at 11:04 AM, Chris Rossi <email address hidden> wrote:
>
> Actually, how about one directory, with one html file with all of the
> events, attachments all in the same folder?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1398072
>
> Title:
> Content representations for Box
>
> Status in OSF KARL4:
> In Progress
>
> Bug description:
> The goal is to put all the content about a community into a Box parent
> folder with the name of the community, then subfolders for each tool.
> We then create content in KARL for each resource in the tool.
>
> Think about the most-feasible representation of a Blog Entry (with
> Attachment), Blog Entry, etc. Even Folder and File objects have some
> extra data.
>
> In fact, the community itself has some data: members, tags. How
> feasible is it to represent various information in a community?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl4/+bug/1398072/+subscriptions