Re: Solomon''s curse and search Bias

Apologies, contagious = contiguous

On Mon, Mar 4, 2019 at 6:58 PM Sherman Monroe <sdmonroe@gmail.com> 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,
>
>
> 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)
>


-- 

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)