You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This task is currently on hold pending design discussions.
The very simple logical architecture of peck and intersect is quite powerful. You can run a sequence of peck searches, say
peck "search 1" FRM_01 ~/Out1.csv
peck "search 2" POS_01 ~/Out2.csv
peck "search 3" NER_03 ~/Out3.csv
and so on
and then get the intersection of all of them through pairwise recursion:
intersect ~/Out1.csv ~/Out2.csv ~/Out12.csv
intersect ~/Out3.csv ~/Out12.csv ~/Out13.csv
and so on
In designing a front end search interface, it may be that a very different logical design is better -- let's say, we assume we have the dataset in a database somewhere, and can search it along multiple dimensions at once. The advantage with the peck / intersect design is that it's conceptually very simple, which is important not just for the programmer, but for the user.
If we do use the same architecture, it means the task can focus on implementing peck first, leaving the intersect function for later. This would simplify the development process. The task is bacially, "Implement peck in a web interface" -- having a working implementation is a great task specification.
It would also mean that the interface could be simplified. Basically, the user would just have to choose a primary tag first, from a menu of primary tags. Then a new screen comes up with the options available for that particular tag. The user performs a search and get a result, done. For the next search, start all over.
The search engine generates a list of research results. The user can then selectively check off files in that list and press "Intersect". Intersect is intransitive.
The text was updated successfully, but these errors were encountered:
This task is currently on hold pending design discussions.
The very simple logical architecture of peck and intersect is quite powerful. You can run a sequence of peck searches, say
and then get the intersection of all of them through pairwise recursion:
In designing a front end search interface, it may be that a very different logical design is better -- let's say, we assume we have the dataset in a database somewhere, and can search it along multiple dimensions at once. The advantage with the peck / intersect design is that it's conceptually very simple, which is important not just for the programmer, but for the user.
If we do use the same architecture, it means the task can focus on implementing peck first, leaving the intersect function for later. This would simplify the development process. The task is bacially, "Implement peck in a web interface" -- having a working implementation is a great task specification.
It would also mean that the interface could be simplified. Basically, the user would just have to choose a primary tag first, from a menu of primary tags. Then a new screen comes up with the options available for that particular tag. The user performs a search and get a result, done. For the next search, start all over.
The search engine generates a list of research results. The user can then selectively check off files in that list and press "Intersect". Intersect is intransitive.
The text was updated successfully, but these errors were encountered: