humanitiesplusdesign / data-pen Goto Github PK
View Code? Open in Web Editor NEWPersonal modeling application for Linked Data.
Home Page: http://hdlab.stanford.edu/fibra
Personal modeling application for Linked Data.
Home Page: http://hdlab.stanford.edu/fibra
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.
Initially should just display the sparql-item-component
Show me what is the big deal about Linked Data.
We need to demonstrate
When a node is selected it changes size and color, but never changes back after it is no longer selected.
Additional to #26
But, should we then store a component's template in the same directory as the component?
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!
At the moment, will probably go with client-side management of the currently displayed items. @jiemakel is thinking further about this.
Should respect:
Initially, this should return nothing.
Several issues (please add more):
Relationships between entities of the same type can have various levels of structure:
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.
Should surround the primary node as per the mock-up.
Only display a single node for things that are "sameAs" each other.
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.
(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).
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.
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?
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.
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.
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?
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?
May already exist, but Alex and I aren't clear on how to go about this.
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)
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.
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.
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:
Queue actions would need to define the following:
For example, an action to add an item would do the following:
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):
undo
methodstate
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.
Dependent on #19
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.