The 'wants to share' column is not required to pay the royalty. The issue here is getting useful entries in a usable format, so the gradation of high quality/low quality is important. The bulk of the 'content editing' approach will be geared towards this column.

There are two general types of users here –those who really want to share their information and are willing to do extra work to comply with a quality standard and those who don’t want to or are able to comply for a variety of reasons.

We (whoever is responsible for this) would provide an authoring guideline along with the database. I am attaching a document I prepared years ago that could be a basis for such a guideline.

Users who don’t pay a royalty would send us the following:

If the user has not modified the software and uses the software to create entries, there will be an easy utility to ‘Send Changes’ which will send all changes since the last time this utility was run. This could be based on the current script utility. My suggestion is that this is once a quarter. In some instances PIF/XPL would be easier for the editors, but my assumption is that we want to err on the side of ease for the user to encourage propagation of the tool/content.

If the user has modified the software, the Script utility may not capture the changes they make and we would ask for a ‘Send Extract’ which will send a current state of the database (equivalent to a PIF or XPL starting at Root). Again I would suggest once per quarter.

If the user is not using the software at all, then we may just get a description of the changes in text format. I do have a question if this should fall under the license agreement at all. If text is an issue, then I’m not sure what we would require them to publish/send. Perhaps a copy of their database? Again, once per quarter.

In all of these cases I feel the ‘copyright’ for new content belongs with the new author, even if we are requiring them to publicize it. I have a question as to whether moving existing entries around is the same as adding new entries.

In addition to these required sending of files, we should allow/encourage users to share URL’s for their local webservers. We would have a central webpage that would have a listing of these links, a sentence or two describing the data and an email contact (perhaps not including any spammer links).

The above procedures probably work for the upper cell (High Quality). The lower cell is more problematic. Users may send us junk files. They have complied with the license terms, but the entries are unusable. These may be unusable because the users are

Spammers – sending us junk on purpose. These files would be deleted en masse.

Sandbox – early entries from quality users that are not up to snuff. For example, I create many entries that I then delete later that would be sent by the scripting utility. These may be very difficult to weed out and may be the biggest editorial time sink.

Computational – quality entries that are in a format unusable directly by OPHI that would require manual re-entry.

Avoiders – people who send us entries intentionally not up to snuff just to get out of paying the royalty but not wanting them to be published – e.g. send us the entries in Pig Latin.

Note that people have to pay the royalty to be in the second column after a period of time (6 months.)

The issue here is payment enforcement.

I defer that to the licensing team to discuss.

Okay, so we have dozens of scripts and XPL/PIF’s- what now?

My assumption is that there will be some sort of editorial tool that will allow browsing/accepting of script or XPL/PIF changes. Note that these tools may not be available at start-up. As time permits, a group of editors can go through and accept changes. These would be of two general types:

Adding a leaf that would link out to a remote database. This could be my ASU Purchasing example. We (the editorial body) would add a new leaf to the "Buy – Views" bundle called "Buy {ASU}" In which the description would be: "Arizona State University has a Center for Advanced Purchasing Studies which has added a taxonomy of purchasing types. You can click here to go to their Process Repository" Where the link goes to process.asu.edu/process handbook and may even log you in and go directly to the appropriate entry, although it will be obvious that you have switched domains. One entry is added to the centralized repository linking to (let’s say) 100 entries at ASU.

Adding the whole branch. In this case we would script or XPL/PIF in the entire ASU taxonomy as part of the "Buy {ASU}" branch. 100 entries are added to the central database. Needless to say, this requires more editorial work.

My proposal is that adding entries to the central repository happens in four stages:

1. Email listing of user contacts happens upon download
2. URL directory listing happens when the users set up a site.
3. Adding a leaf happens relatively soon after the quarterly submission if the editorial board thinks this makes sense.
4. Adding the branch happens after more thorough editorial review and may take an extended time.

The editorial board would consist of the ‘usual suspects’ (Kevin, Brian, George, Jintae, etc.). We would have a procedure for adding a leaf that might be quick and a more thorough process for adding branches. This may be split by area of expertise, allocated by availability or whatever. There would be one ‘editor-in-chief’ responsible for managing the process, although that person might have no additional editorial capabilities.

In addition to adding entries, there might be modifying or deleting of entries. Approving the modification of ‘attributes’ on ones own entries should be a relatively quick process. This includes things like changing descriptions or decompositions if the decomposition entities are also by the same author. Moving/deleting entries within ones own ‘domain’ (down a wholly authored branch) should also be quick. Moving to another author’s branch or editing another author’s entry would be suggested to the editorial board.