Re: Solomon''s curse and search Bias

>
> Sherman and Thomas P
> thanks a lot for sharing your search journey with friendly narrative and
> about this project. Looks really neat!
> I am still thinking about the need to carry ot some structured data search
> on open web via  general search engines tho.  I hope Google may consider
> adopting your architecture or at least some of these ideas which in
> principe work at least within a closed data set,


Paola,

You are most welcome, and thank you for sharing this interesting problem.
Structured and unstructured data are the yin and yang of a smarter web,
each complements the other and both are necessary. I expect we will see
greater fusion of the structured and unstructured data webs in times to
come.

Hi TomP,

Thank you for the reference to your work, I look forward to learning about
your ideas and perhaps they will help improve our interface.

Another point to keep in mind is that a good user interface must be very
> different for a small project as contrasted with one that encompasses a
> large collection of data.


This is something we encountered earlier on. We wished to allow user to group
the result set by a certain field <http://bit.ly/2IQaC4o>. The first
prototype used a drop-down menu to store the fields list for user to select
the grouping criteria, but there are many fields (pages of them). So we
instead reuse the fields list. When a field is selected, an icon appears
adjacent to it and when clicked, the records list is grouped by that field.

The kinds of things you are trying to explore can also be approached
> using a framework of library science, and specifically the concepts of
> "navigation" and "collocation"


Collocation is a genetic feature of RDF, e.g. when classes and properties
are viewed as facets of the subject that can be toggled. Query relaxation
techniques
<https://www.semanticscholar.org/paper/Answers-Partitioning-and-Lazy-Joins-for-Efficient-Ferr%C3%A9/488dff441f61c7c290ae0d2904a6fbc3c0f88392>
can also aid in serendipitous discovery. We feature a trivial version of
this with the Expand Search button and Remove Keywords button, for
instance, try removing the keywords from this list of movies
<http://bit.ly/2J5Rtvt>. The result is this nearby list
<http://bit.ly/2IR9mxC>. We plan to introduce features similar to this
later on.

"A subject language is
> a vocabulary for describing the subject of a work in such a way that it
> can be recognized and thereby found — that is, to provide navigation
> capability for a collection."


The application of collocation to bookmarking is quite interesting, as is
your use of fully-qualified paths as topic id's, which our work also
quickly gravitated towards (i.e. our permalinks can be considered topic
paths in your subject language). I am interested in web services navigation
paths <https://ieeexplore.ieee.org/document/5552808>, specifically, the
idea of indexing browsing history around user's activities, as implied by
the web services actions they invoke as they browse and use the web. This
sort of metadata would allow for an activity-centric perspective of
browsing history. The principle behind this is that, if user cannot recall
the link they found, then perhaps they can recall what they were doing when
they visited the link, or maybe viewing a list of their course-grain
activities within a certain time-frame would help jogged their memory of
the specific activity they were occupied with. Browsing history would be
logged as normal by the browser, however web services would be socially
(and/or personally) annotated to mark the beginning or ending of an
"activity mode", for example "researchgate.net=research mode". Then a
calendar view of the browsing history could sort URLs as contagious nodes
within the activity modes. This reduces the set of URLs requiring manual
annotation, i.e. only the trigger URLs would require annotation.

In linked data, the general solution to the search/find problem is to link
every URI to as many meaningful things as you can, then provide a browser
which allows user to *configure* their way to the answer of a certain
question using property filters to build what is essentially a SPARQL query
that enunciates the user's question.

-sherman

On Mon, Mar 4, 2019 at 8:01 AM Thomas Passin <tpassin@tompassin.net> wrote:

> On 3/4/2019 6:54 AM, Paola Di Maio wrote:
> > Sherman and Thomas P
> > thanks a lot for sharing your search journey with friendly narrative and
> > about this project. Looks really neat!
> >
> > I am still thinking about the need to carry ot some structured data
> > search on open web via  general search engines tho.  I hope Google may
> > consider adopting your architecture or at least some of these ideas
> > which in principe work at least within a closed data set,
>
> The kinds of things you are trying to explore can also be approached
> using a framework of library science, and specifically the concepts of
> "navigation" and "collocation".  Collocation means that items that are
> somehow similar can be found "near" each other in some sense of the word
> "near".
>
> For a look an an attempt to provide good navigation and collocation for
> a small private data set, you could look at my paper "Browser bookmark
> management with Topic Maps" for the Extreme Markup Languages conferences
> from 2003 -
>
>
> http://conferences.idealliance.org/extreme/html/2003/Passin01/EML2003Passin01.html
>
> This work was my effort to get the most out of very limited amount of
> information, namely, titles of web pages. The viewpoint behind the work
> derived from the library science concepts of collocation, navigation,
> and "subject language".  To quote from my paper: "A subject language is
> a vocabulary for describing the subject of a work in such a way that it
> can be recognized and thereby found — that is, to provide navigation
> capability for a collection."
>
> Another point to keep in mind is that a good user interface must be very
> different for a small project as contrasted with one that encompasses a
> large collection of data.  Just for a tiny example, a pick list for ten
> items can be usable whereas one for 10,000 items is not.  A UI for a
> large data set is hard to design even if your system has good
> collocation and navigation properties.
>
> TomP
>
>
>
>

-- 

Thanks,
-sherman

Every good gift and every perfect gift is from above, and cometh down from
the Father of lights, with whom is no variableness, neither shadow of
turning.
(James 1:17)