humanitiesplusdesign / data-pen Goto Github PK

Should respect:

1. Configuration
2. Selection
3. The currently selected items on the canvas

Initially, this should return nothing.

May already exist, but Alex and I aren't clear on how to go about this.

Show me what is the big deal about Linked Data.

We need to demonstrate

1. adding a node to the canvas
2. Verifying that node against one or more authorities
3. Adding related entities to the canvas

#26

• Authorities
  • Pleiades
• Archives
  • Pelagios datasets
  • Nomisma coin hoard datasets
  • Perseus Catalog

At the moment, fibra.SparqlItemService.createNewItem doesn't appear to work. It runs, but no item is added to the current selection. It is currently triggered by searching for an item and adding it. I suspect it is not working because the type is no longer added.

Only display a single node for things that are "sameAs" each other.

Similarly to adding links, what exactly are the steps for adding new nodes in CONSTRUCT?

My initial thoughts are that when you are in "drawing mode", you constantly see a phantom node at the nearest grid point. Right clicking or similar will then add a new node there, with its type defined by the layer it is on. It will then immediately also ask for the new node's label.

But just the label, or should it also provide a form for other properties?

Another alternative is that you can just add nodes anywhere (particularly if we're not on a fixed grid - are we BTW forcing the fixed grid, or will we continue to support a non-fixed one?). Then, the type would be selected similarly to the link type (or maybe there in addition could be a dropdown somewhere that shows the current add type and allows you to change it also from there?), and after that we move to adding labels and properties as before.

(adapted from an email to Ethan)

In the RDF data model, ALL relationships/properties are directional. So
Eetu label "Eetu"
is interpreted exactly the same as
Eetu placeOfBirth Helsinki
and
Eetu knows Ethan

All also have (in theory) inverse properties:
"Eetu" isLabelOf Eetu
Helsinki isPlaceOfBirthOf Eetu
Ethan knows Eetu (this is its own inverse property, also called a symmetric property)

Now, in practice, in a lot of data sets, for most properties other than symmetric ones (and most properties in most datasets aren't symmetric), the direction matters in terms of interpretation (and technically, the relationships are often manifested and stored only in one, the outgoing direction). Often,
these "outgoing" properties are used for information "intrinsic" to the entity - names, birthplaces, occupations etc.

Now, taken from the other direction, this then tells that all incoming/inverse properties are where the resource is being used as a "hub" or "tag". This is often also a useful viewpoint, so that one can
see easily for example all people that were born or died in a particular place, but still, this is definitely a different type of information than the label, coordinates or type of that place. Compare e.g. this time to this person.

In that UI, all the inverse properties are just shown separately under the "References" tab, without being grouped by property (note also that for e.g. times and places, the amount of other resources linked to them is often huge, which needs thought in both UI and sometimes in terms of available processing power). And in general, this is quite okay, but since Fibra will focus more heavily on
properties linking like with like, we'll probably want to put in more elaborate handling for symmetric properties, and other similar properties, where the inverse interpretation is very similar to the
original one (e.g. wife <-> husband, child <-> parent, broader/narrower place, chapterInBook/bookContainsChapter, ...)

Now, thinking this through, I'll actually need to probably break them out differently, not in terms of how they're encoded in the underlying data model, but in terms of interpretation/intention.

This whole thing does have consequences also for the graphical explore view, because we'll need to figure out 1) which types of relationships to visualize at all and 2) how to visually differentiation the
different types of relationships (symmetric, meaningful but with a different meaning/label in both directions and unidirectional).

Our partners in the French Book Trade project have made their data freely available here:

http://fbtee.uws.edu.au/main/download-database/

This publication data could be an excellent addition with significant overlaps with our current test data sets. The project lead, Simon Burrows, will be visiting Stanford at the end of October. It's always more effective to demo a tool when it includes material that is off interest to the user!

Relationships between entities of the same type can have various levels of structure:

• Direct, unqualified relationship
  • Eetu knows Nicole
• Direct, qualified relationship
  • Eetu knows Nicole after 2009
• Relationship through a separate entity associated with both (note separate properties relating to the separate entity)
  • Eetu and Nicole are connected through a place because Nicole lives there and Eetu visited there
  • Eetu and Nicole are connected through a letter Eetu sent Nicole
• Relationship through multiple entities
  • Eetu and Nicole are connected because Nicole participates in a Work -event associated with H+D and Eetu participates in a Visit -event associated with H+D during the same timeframe
  • Eetu and Nicole are connected because they both participate in separate Holding events at different times, but regarding the same book

There needs to be a way to move between these different levels of structure, both in adding connections as well as exploring the ones already in the data.

Strategy as suggested by Eetu is to just make the charge force nodes further away from each other than then distance between the grid points.

We need to define actions (add, modify, delete) around entities/items and create a queue concept for managing them client-side and coordinating updates with the server. In service of the following features:

• Fast user-interaction
• Handle server-side failures somewhat gracefully (at least a warning and explanation of what failed and what pending updates have not yet run)
• Undo/redo

Queue actions would need to define the following:

• Client-side update (happens immediately)
• Server-side update and subsequent client-side changes
• Steps to reverse the action

For example, an action to add an item would do the following:

1. Add the item to the current working set on the client-side immediately
2. Create the item server-side, receive the server-side version back, and update the client-side version as appropriate (this is complicated...)
3. Record the steps to undo this action, which would consist of deleting the item.

Because coordinating client-side and server-side data models is hard, we would probably just force the UI to wait until the server-side process completes and the client-side data model is updated in the first iteration, but longer-term we may want to allow the client-side to get several steps ahead of the server-side.

Todos (preparatory to breaking out other issues):

• Move out of fibraService
• Reducers should maintain reversal capabilities and this should be leveraged in the undo method
• Move node representation onto state
• ...

Currently, no properties of imported objects ever get copied to the local data store. This needs to be added to the end of the "import from remote" workflow currently triggered from autocompletion.

@cncoleman, I guess the design on http://hdlab.stanford.edu/fibra/designs/phase1_components/ for Enrich is intended as a base for this?

Additional to #26

I searched for "Charles" in the all datasources configuration and this is a screenshot of the request after a minute or so (it got up to almost a gigabyte before Safari crashed):

Let the user add notes to remind herself of her thinking process

Conversation with Kate and Jac:

Add another "panel" to the view where you can add notes. These would be annotations to links or nodes but also a running set of notes that are captured linearly and can be exported as text.

This UI will be used for expanding the set of items shown in the construct view.

After initial technical implementation, this will need both design as well as API support.

Several issues (please add more):

• One table per type
  • Display local properties not remote properties
  • Tabs for tables of different types (primary node type displayed by default)
• Display locally stored properties only
• Download capability in tabular (CSV) format
• Display cells with multiple properties properly

Currently the structure of the types in selectedTypes looks like:

{value: "http://www.cidoc-crm.org/cidoc-crm/E74_Group", termType: "NamedNode", __className: "NamedNode"}

I think in the type properties of the actual items there is a readable label derived in some way. Would it be possible to have this label information on this object as well?

I am being asked for a username and password when trying to add or delete items. Is there a specific username and password needed for this?

Dependent on #18 and #29

When a node is selected it changes size and color, but never changes back after it is no longer selected.

• Nodes turn green and large after being selected and don't change back
• Nodes turn dark when moved and don't turn back

There's some design for this I've done at https://docs.google.com/drawings/d/18pUS2zRrOkgOEpZiGhRGyQIPGBHacaYsEJnngPxHsRQ/edit (center column), but that doesn't contain everything I've though about. I'll first have to update that design, and then implement it.

Technically, I'm also going to make it work faster.

How does drawing relationships between entities in CONSTRUCT actually work? here and here we have a more typing-oriented UI design, but how do we go about this in the graph view?

My intuition is that we just draw a line (Alex has already added functionality for this), and somewhere in the back we have a default type for this relationship (maybe just a generic 'is related to' for a start, but possibly also different defaults for the different types [e.g. places, people] visible in the graph?) It should then be possible to select a link, and change its type (like in Rhizi, with e.g. up/down arrows?). We could also then default to any new relationships drawn being of the type last added. Should we have a possibility to define new relationship types here, or would that be done elsewhere?

Even if I choose the open configuration, Procope, etc, searches only return results from ULAN and TGN.

I already fixed one bug, but there seems to be something deeper going on here. This is just a note to myself so that I remember to tackle this (needed alsofor making explore respect working set boundaries)

Dependent on #19

At the moment, will probably go with client-side management of the currently displayed items. @jiemakel is thinking further about this.

Initially should just display the sparql-item-component

Our main.styl file is cluttered, and probably contains definitions no longer in use. We should organize our CSS stylesheets into separate files depending on scope (whole app or individual component) and/or by purpose.

I've started this by moving some of my definitions out of main.styl into sources.styl. Please do the same with your definitions, and add // explanatory comments to those global definitions still actually in use.

After syncing with the most recent changes and running npm install, I'm getting the following error message:

None of the previous items are showing up in the table or the explore tab for me right now.

Before CONSTRUCT users pass through CONFIGURE and SELECT. As we build CONSTRUCT we need to have some pre-configured and pre-selected options. But we still need to have more than just names for the configuration and the selection.

Configurations should show the list of source.

Selections should give us some basics stats: how many records? How many of each type of entity? (assuming we are pre-limiting the entity types?)

The CONFIGURATION is the library. I want to know the sources. The SELECTION is the set of books in my carrel or on my office bookshelf. I need to be able to browse them easily.

For robust testing, we want to have multiple test scenarios with both 1) different datasets configured (Early Modern / Ancient config) and 2) different data in the current working / visualization set (to simulate individual researchers' individual sessions/tasks/questions).

I'll add the support needed for storing and switching between these into the code and supporting infrastructure, though the ability to create these in an UI will come at a significantly later stage.

But, should we then store a component's template in the same directory as the component?

Should surround the primary node as per the mock-up.