runjak / transcriptiondesk Goto Github PK

The TranscriptionDesk shall have 3 cases where voting can occur:

1. On the completeness of scans.
2. On the choice of AOIs.
3. On the transcription of AOIs.

The tables for these votes look very similar and voting is evaluated in the same way for all of these.
Therefore it makes sense to encapsulate all of these tables into one logical entity (class or class hierarchy) and a similar web interface, that reuses common parts and only specializes where necessary.

Our current understanding of voting is this:

• Users can vote up or down if no consensus is reached.
• Consensus is reached if the up or the down votes outweigh the others by a lead of 5.

We need to decide on a LICENSE file for our project. I believe @ThomasK81 said some Creative Common flavor would be preferred.

I'm still improving the project report, currently up to L240.

@runjak: please fill in L240 subsection with keywords (I will phrase that later) and look at %FIXME at L229

Areas of Interest need their own class to represent db entries.
They have URNs with an already defined schema.
This schema needs to be validated, parsed and instantiated.
We need to be able to store and modify(copy on write) such Areas of Interest,
along with capability to discover them in some way via the site.

Figure out which MUFI characters we need and implement them in some kind of input system that allows users entering markdown to also input MUFI characters.

• Figure out how the Omeka API works
• Build some PHP code (yay!)

Chart.js apparently doesn't work anymore properly.

In commit a10a539 I added several product functions. I would like feedback if they are OK as they are, if some aren't needed etc. . Also within them there are a lot of underfull \hbox. If this is a problem please let me know or resolve this issue.

intro.js may be a good choice for tutorial functionality in this project. Please have a look at it .)

• Possibly use Bootstrap?
• Create HTML templates for anticipated views a user will see

I still get invalid authentication errors after updating the database. Maybe its a redirect problem, maybe something worse. Will keep searching.

• Remember to tack timestamps on everything possibly useful
• Design with URNs in mind
  • SQL allows selection by prefixes, which might come in handy
• Create an ER diagram
• Produce working SQL to create tables

It looks like we will install Omeka to manage our image content. I have prepared an instable mock-up. It runs from a computer that is not always online. However we will move it to our server Homer within the next two weeks.

All images are TIFF or JPEGs.

Although Omeka has some support for transcriptions: e.g. Scripto. It would be good to see alternative transcriptions desks with polygon marking up and a Markdown based editor.

I changed the raw design of those 3 pages, I would like to get some input if it looks alright, and what changes could be made to make it look better.

• User registration progress via github, facebook, google (oauth)
• User login/logout
• User profile page

Item 41 has no Identifier/URN provided.
If this Item is to be included in our database, a URN will be necessary .)

Goal is to create a user specific profile page that displays some relevant data (e.g. scores, activity, etc.):

• It can be a mock up
• Charts need to be supported
  • Shield UI (?)
  • Clarification which type of chart should be used for what datasets

Authentication mit Opauth ist deutlich einfacher mit Vagrant zu realisieren, da gegenüber Docker keine wechselnden IPs vorhanden sind.

Transcriptions need their own class to represent db entries.
This task is similar to issue #9, but instead should aim to deliver the same
needs for transcriptions.
Note that transcriptions have some differences to AOIs:

1. They have categories, which need to be put in the schema + ER + other stuff.
2. They will need a method for export to GitHub later on.
   Similarities are:
3. URNs
4. copy-on-write

There is an Omeka item with the URN urn:cite:ogl:bnf_7989.
All files belonging to this item have a filename like DigitalPetronius/urn_cite_ogl_bnf_7989/bnf_lat7989_195.jpeg.
I presume, that the URN for such a file would than be urn:cite:ogl:bnf_lat7989_239.jpeg?

The tricky thing here is that bnf_7989 is not a prefix of bnf_lat7989_239.jpeg as I originally expected.
Since the files themselfs don't carry URNs in Omeka, we have to derive their URNs by combining the file names and the URNs of their items.

While we've had good discussions about the layout of our own URNs,
we haven't touched the issue of file URNs so far.
What would be the expected way to generate URNs for files?