periodo / periodo-client Goto Github PK

View Code? Open in Web Editor NEW

15.0 15.0 3.0 80.58 MB

Client to browse and edit PeriodO data

Home Page: https://client.perio.do

License: Other

JavaScript 97.30% HTML 0.37% Makefile 0.87% Python 0.11% PEG.js 1.30% Dockerfile 0.04%

gazetteer indexeddb javascript json-ld linked-data periodization react

periodo-client's People

Contributors

Stargazers

Watchers

Forkers

weberjavi maxwelllincoln solmazsere

periodo-client's Issues

Sync with server

Shouldn't the call to our server result in my browser downloading a local copy of all the data, which it would then display when I navigate to test.perio.do, until I perform a new sync? Currently it always begins with a blank screen, and I have to sync each time. If we're going to allow local/offline work, presumably the synced data need to persist locally until the next call.

Cancel button in Add Period editing window does not work in Firefox

I started to add a period to a local collection I'd made for the CHGIS periodization, but then decided I wanted to cancel it out to fix a mistake in the previous period I'd added. Clicking the cancel button did not cause any change to the state of the page. When I hit the back button on the browser, thinking I could back out, the client reverted to the database selection page -- and when I tried to access the local idb, nothing appeared but the following error message (the database seems to have disappeared, even on reload):

Delete local idb button does not work in Firefox or Chrome

Can't delete a local dataset.

additional date formats I've encountered

To add to the list of date formats we will encounter:

"tenth century BC" (written out rather than numeral like "10th c.", relatively common)

"1400-1350/1300 BC" (which seems to be equivalent to saying "some time in the second half of the 14th century)

JSON-LD/RDF view

Is this going to reappear as a visualization option in this version of the client? Data model aside, it would help to surface some of the information we're hiding (e.g. if the language/script identifiers from the spreadsheet made it in or not). Also, it's good for letting people have a quick look at how the period definitions are structured in practice.

Period sort logic in client

Make it possible to sort period definitions in a period collection by a) start date of the period (earliest to latest and vice versa) and b) alphabetical order. Right now they appear in neither order, which makes them hard to look through for the user.

provide list of previous periods in a periodization/period collection in the data-entry page

Via @atomrab: It would be helpful to have a list of the other periods in a given periodization/period collection on the page for the entry of a new period. This would help the user remember which periods from a large collection had already been entered, avoiding duplicates. It would also help to catch errors or typos in dates, since it would be more obvious that there was a gap or overlap between the existing period spans and the one being entered.

502 Bad Gateway for ORCID auth

Attempt to authorize PeriodO client to get ORCID produces 502 Bad Gateway error even when already logged in to ORCID system:

Memory leaks all over the place

Objects are not being freed as a user navigates through the interface. This might have something to do with how we're using backbone-relational.

Not urgent (since things are working), but I think we should get away from that library in the future. It does much more than we need and doesn't exactly fit our use case. We might look into using AmpersandJS models, which allows parent/child relationships.

Add author as a column in period table

Source title, No. of definitions, and Time span are visible, but add Author to this display: http://perio.do/periodo-client/#sync/

Add link to Periodo project site somewhere

"Locator" property of period definitions not correctly translated in form

Locator property should be nested, like:

"source": {
  "locator": "page 367",
  "partOf": "http://www.worldcat.org/oclc/47825690"
}

Currently, the form just serializes it as "locator": "page 367".

maintain and display original start/stop and spatial coverage text

via @atomrab: I wanted to move our discussions into the issue tracker, since I've found that as productive, if not more so, in other projects than long email threads.

I don't know if one can add categories for labels for issues, but I'd like to have something to set apart actual bugs, enhancements, and questions from larger theoretical issues. Does anyone have a suggestion for a tag we can put in a title for bigger-picture issues like this one? Or is this just really an enhancement?

Now on to the issue.

I wanted to submit this issue to check in with you and Ryan about the display of the periods entered in the client you're building. One of the principles I assume we want to maintain is the preservation of the original terms in which a given period was described (so even if we're representing it as ISO dates, we keep the original statement that it was "early 5th century BCE-25 CE" etc.). Right now it looks like BCE, for example, gets translated to BC, and ISO-style dates (e.g. -700) aren't recognized by the parser.

Obviously we'll need to normalize the dates on the back end and in the representation, but I'd find it helpful if the edit/browse interface retained the original label for display, either alone or in combination with the normalized ISO dates. I think it makes most sense to be explicit about any transformations that are happening between the temporal coordinates as expressed by the source and the information we're collecting.

Right now I think it's impossible not to mask the spatial transformations, though -- so when someone says that a period applies to "Mesopotamia", we're stuck making some deductions about the modern nations to which that applies. It will be interesting to see if we can get anywhere with ancient gazetteers or data sources -- Pleiades or maps of the extent of the Roman Empire, for example. But here too I'd be in favor of being as explicit about deductions as possible.

Handling spatial coverage

Adam in #23:

For spatial coverage, I'll take anything that can provide URIs and polygons for regional administrative divisions (e.g. "Sicily", "Toscana", "Texas") and for continental aggregations (e.g. "Europe", "North America", "Africa"). Geonames will at least resolve eastern, southern, northern Europe etc (e.g. http://www.geonames.org/7729883/northern-europe.html), and handles regions (e.g. http://www.geonames.org/2523119/sicilia.html). Does DBpedia do this too?

Exposing our URIs

I don't know when we plan to make these part of our records (when we have a more permanent server home?), but it's going to be important quite soon to allow users to see and copy these (e.g. with the ARIADNE use case).

experiment.worldcat.org does not serve HTTPS

From the "no good deed goes unpunished" file-

Since we switched the site to be served over HTTPS, we can no long make CORS requests to worldcat.org because it is only served over HTTP.

China does not come up in the spatial coverage lookup

I tried China, People's Republic of China, Republic of China, Zhongguo -- nothing. Could this really be missing from DBpedia? If so, perhaps a good reason to allow spatial lookup against a gazetteer of the user's choice.

"Select all" radio box on Sync page does not select all

In Chrome, checking the "Select all" radio box on the Sync page does not select any of the period collections in the list. The "Select all" radio box on the patch submission page does work, however.

Clicking "edit period collection" button in local copy switches you to the web backend

I. periodo-client backend with synced dataset
2. click on Hodos 2006 collection
3. click "edit period collection"
4. URL changes to https://test.perio.do/#periodCollections/p0tns5v/edit/, but action is just to switch "current backend" at top of page to "web" (edit window does not come up)

Language/script selection window doesn't close on ok in Firefox

When a language/script is entered, the entry is updated, but the window will not close when the "ok" button is clicked (in Firefox 38.0.5).

Permalink

I suspect this doesn't matter right now, but the current period-definition-specific permalink resolves to the collection as a whole, and then for some reason incapacitates the browser back button in Chrome (it just sends you back to the same page again). Eventually we probably want to support resolution down to the period record, since human users may want to follow the link from a database.

Example of attempt to enter a period -- what's missing from interface currently

Here's a concrete example. We're trying to add a period from Twist 2001, which exists as a collection in the server dataset. The period, diagrammed on page 17, is called "Copper (Chalcolithic Age)"; it lasts from 3200 BC to 2500 BC in "Europe", and is a sub-period of "the Metal Ages".

Currently we can represent the label and the dates. We can construct Europe from all of its component countries, but it would be much more useful if we could point to a spatial gazetteer that will work with larger and smaller concepts -- currently we can't do "Europe" or "Sicily", only discrete nations.

We also need to include information about language and script (lat, eng); original label (Copper); alternate label (Chalcolithic Age); English label (here probably Copper Age is best, inferring that's what the author meant by "Copper (Chalcolithic Age)") and source locator (page 17). This source also has a lot of broader/narrower relationships, which we probably want to capture at this point.

How much of this can we push to the editorial notes field, to return to later, before we create a situation where we end up doing work twice by hand?

Handle editing "partOf"-type sources

Navigation: returning to list of period collections from a particular collection

Right now, when you select a particular period collection/source, you can't get back to the list of collections without hitting the browser back button, which takes you to a blank page where you have to sync again with the server.

Make rough implementations of visualizations

Before spending too much time on any specific visualizations, we should come up with a melange of rough demonstrations

Linking an author without LD citation

Can we query VIAF for an author ID in the source field even when the user doesn't have a WorldCat etc. citation? For example, adding the CHGIS material, I put in "Merrick Lex Berman" -- would be nice to attach him to the VIAF entry. If so, we will have to specify how the name should be entered (last name, first name or first name, last name, etc.).

Redirect to show individual period collections / definitions in client

Currently browsing to http://n2t.net/ark:/99152/p06xc6m redirects to https://test.perio.do/#6xc6m, which should load that period collection, but it doesn't. Instead https://test.perio.do/#periodCollections/p06xc6m/ shows the period collection.

Likewise http://n2t.net/ark:/99152/p06xc6mvjx2 redirects to https://test.perio.do/#6xc6mvjx2, which currently does nothing but should also show the period collection view with that period definition highlighted and scrolled to.

Workaround for data cases without a URL or DOI

Accept text in the text block that is not a URL or a DOI, i.e. data dumps (in XML) not published elsewhere : "Add periodization," http://perio.do/periodo-client/#periodizations/add/

Filtering by spatial coverage

@atomrab in #54 suggested that filtering could be done by spatial coverage entries (not just spatial coverage descriptions, as is currently implemented).

This may be useful but confusing/misleading because of the relationship between spatial coverage description (which is in the source) and spatial coverage (which is an estimation of that description using linked data entities).

Filtering by spatial coverage will ideally be done in a map interface- this was the primary purpose of linking descriptions with LD entities in the first place. This will be quite involved and not possible to implement this summer.

I think we should hold off on filtering by constituent parts of spatial coverage descriptions ("spatial coverages"), and stick with filtering only by descriptions. The latter will become much more useful once periodo/periodo-data#24 is resolved.

Filter range in main page

What's determining the year range of the filter at the upper right? I love this as a strategy, but using the web backend, it only shows -50000 to 2100 for the dataset as a whole. If this is just for the first page, it doesn't adjust with subsequent pages. If this is for the whole set, the earliest date is too late (we go back to 1.5mya already, and soon will go back a lot further with geological stratigraphy).

Expose more complete collection references in client

I think users are likely to want complete bibliographic references for the sources we're attributing collections to. Right now, these don't appear at all in the web interface, and they only appear in a local idb when you select the edit button. Either providing a full reference in the GUI by default, or allowing expansion (as we now do with periods, which is working really well), is a better option than the very abbreviated author-title-date that we offer now.

When editing existing period the header should say "Edit Period"

Right now it says "Add Period", which could be confusing.

Add edit button for period collection

If a mistake is made in the creation of a period collection, there's currently no way to go back and fix it or add to it. The attributes of a period collection need to have the same editorial control for authorized users as the period definitions within it.

bootstrap.css.map 404

This is extremely minor, but when I load the client in Safari and turn on the developer tools I get this error in the console:

[Error] Failed to load resource: the server responded with a status of 404 (Not Found) (bootstrap.css.map, line 0)

I guess this is because Safari automatically looks for CSS source maps? Any reason not to include one?

RDF/Turtle view does not currently work

The RDF/Turtle display button currently does not work in either the local or the web backend in Chrome.

Display date type in user interface (or display both label and normalized ISO8601 dates?)

When browsing the Fasti periodization, there are two date types: BC dates from a semi-formal Ukrainian periodization, and BP (2000) dates from the main periodization in use on the site. The BP dates show up as just the numbers from the label, but this doesn't make any sense to the user without an explanation that the dates are in BP counting back from 2000 (especially confusing because of the Ukrainian BC dates). We need a way to display either the date type, so the user knows what he or she is looking at, or the normalized ISO8601 proleptic Gregorian dates we show in the JSON, or both -- but we're not showing enough to make sense right now.

Allow sorting in faceted browser

By label, start date, end date

Display Source/Date of periodization in period collection page, not title

Currently the client lists the periodizations by title, but this is both awkward (some of the titles for the web-based versions are not very informative) and not the way specialists are likely to find information (non-specialists will just want a free-text search). It would be one thing if titles provided information about spatial and cultural coverage, but they don't always (e.g. "Periods used on the database").

Academics are used to looking for the authority name and the date (eg Harvard citations), and I think it makes sense to list the periodizations by that header, rather than title. So instead of "Aegean Bronze Age", we might consider "Shelmerdine 2008". There's already a listed date range; if we're worried that it will then be unclear what places are described by this periodization,could we add the spatial coverage for the work as a whole?

Problems with patch generation/submission

Let's put anything that comes up when trying to submit a patch to the server here.

Display and edit of locator and sameAs properties for period definitions

Currently there is no way to see or edit the locator or sameAs properties. The latter is necessary to start entering the BM data.

Can't get sign-in function to work

The sign-in link is not currently working on either Firefox or Chrome.

Adding derivedFrom relationships

Need a way to add derivedFrom relations between period definitions. Need to resolve periodo/periodo-data#15 first.

Client IDB not available in either Firefox or Chrome

I'm not sure if this is a function of being unable to log in (I cleared my cache to see if other issues would resolve; I had previously been logged in, and able to see the IDB on Firefox but not on Chrome) or a problem with the interface, but my only options are to either use the view-only web back end or to make a new back-end of my own (which doesn't work when I click Add in either Firefox or Chrome). Is this intentional?

Patch submission and syncing

@atomrab @sarahab

I'm 75% of the way through patch submission and syncing code, but I don't have time to work on them again until Wednesday. Because I didn't have a chance to finish this weekend, some things are going to be wonky in the version I just released (0.4.0).

Pulling changes from the server ("syncing") is probably not working when attempted from non-blank local backends
Patch submission will probably show a preview but doesn't actually let you do anything

You should, however, be able to add and edit period collections and periods. Once I have a chance to finish, local changes ("patches") can be sent to the server.

Implement patch accept interface

Users are now able to submit patches, but they cannot yet be accepted

Update readme

include links to papers about architecture (SAVE-SD and IJDL)
clarify how we're using browserify
add instructions for installation, testing, releasing

Minor: adjustment to Original Label/Alternate Label

Entering Chinese periods where the original label is in Chinese script, it occurred to me that we should a) find a better way to let the user see the English label for non-English items (right now you have to open the edit window); and b) clarify the "alternate label" field, which doesn't distinguish between the primary English translation and any other kind of alternate label. We should make sure that there's a primary English version that can be accessed easily by the user wherever possible -- right now, a non-Chinese-speaking user won't be able to figure out Chinese periods.

Minor: "source is linked data/source is not linked data" confusing

It's not clear from the user interface that here we mean "CITATION has a linked data representation in WorldCat etc", rather than "Dataset is represented as linked data". Change wording with reference to citation to avoid confusion?

Bad gateway error again with ORCID login

I'm getting a 502 bad gateway error with ORCID again: first I got a bad gateway when I entered my (correct) login information, and then, when I tried again, I got the ORCID notification that PeriodO wanted to share my information -- but when I clicked "accept", the 502 bad gateway message returned.

Recognize Date qualifiers in the 2nd data entry page

The first data entry page/step is "Add period collection" (5 fields). The issue occurs in the second data entry page/step, "Add period" (7 fields). Two of these fields, "Start" and "Stop", currently only accept a raw number for a year. We need to add capacity to recognize a date formatted like this example from the BM dataset: 749 (AH 132). Also BC, BCE, etc.