Re: [Semediawiki-user] Simplifying Semantic Drilldown

[Joel N. <joe...@gm...>]

Hi Yaron,
Thanks for the hint.

And revisiting "caching" Semantic Drilldown, the cached drilldown file
perhaps, can even be used with MigaDV, as an offline browser of an SMW site.

Best,
Joel

=======================================================
Think Different! (http://en.wikipedia.org/wiki/Think_different#Text)
Imagine Different! (http://www.youtube.com/watch?v=H5tOgRD4EqY)


On Wed, Aug 7, 2013 at 12:36 PM, Yaron Koren <ya...@wi...> wrote:

> Hi,
>
> Thanks for the feedback.
>
> Joel - you can already exclude categories from the drilldown, using
> __HIDEFROMDRILLDOWN__.
>
> -Yaron
>
>
> On Wed, Aug 7, 2013 at 12:13 PM, Joel Natividad <joe...@gm...>wrote:
>
>> +1 for smart filtering, but still give admins the ability to optionally
>> tweak the default behavior on a category by category basis and perhaps,
>> exclude the category from semantic drilldown.
>>
>> While you're thinking about SemanticDrilldown, you may also want to think
>> about how to make it more "performant" for large sites, maybe even explore
>> the concept of doing "cached" drilldowns that are precomputed on a schedule
>> (think generateSitemap<http://www.mediawiki.org/wiki/Manual:GenerateSitemap.php>
>> ).
>>
>> Best,
>> Joel
>>
>> =======================================================
>> Think Different! (http://en.wikipedia.org/wiki/Think_different#Text)
>> Imagine Different! (http://www.youtube.com/watch?v=H5tOgRD4EqY)
>>
>>
>> On Wed, Aug 7, 2013 at 10:37 AM, Yaron Koren <ya...@wi...> wrote:
>>
>>> Hi everyone,
>>>
>>> You may have seen the project I released last month, the Miga Data
>>> Viewer:
>>>
>>> http://migadv.com
>>>
>>> In brief, it's a Javascript-based application that provides a browsing
>>> interface that's somewhat similar to Semantic Drilldown, but more
>>> generic,
>>> and it can handle any structured data, not just data from Semantic
>>> MediaWiki. (There are a few other differences, like that the interface
>>> can
>>> work offline.)
>>>
>>> Miga is based around the "Data is data" theory, described here:
>>>
>>> http://wikiworks.com/blog/2013/02/06/data-is-data/
>>>
>>> In brief, it's the idea that the best way to display, and browse, a set
>>> of
>>> data can be determined solely by the size, structure and layout of the
>>> data, not its subject matter.
>>>
>>>  I bring all this up because creating Miga has made me reconsider some of
>>> the design decisions behind Semantic Drilldown. Miga takes a simpler,
>>> more
>>> automated approach to browsing: when a user filters on a number or date
>>> property/field, Miga generates the set of ranges for that property/field
>>> automatically, based on the current layout of the data. With Semantic
>>> Drilldown, conversely, the admin specifies the ranges ahead of time: for
>>> Number properties, the admin has to specify ranges like "0-9", "10-99",
>>> etc., while for Date properties they have to specify whether the values
>>> should be subdivided by month or year (those are the only two options),
>>> or
>>> whether the input should be a date range, with a "start" and "end" input
>>> for users. Besides being more work for admins, this approach results in a
>>> more inflexible system.
>>>
>>> To take an example: a wiki has a category holding buildings, including
>>> properties for the date they were completed, and their height. Both of
>>> these have filters in SD, and the admin picks a reasonable setting for
>>> the
>>> completion date (filtering with a date range, since the time span is in
>>> hundreds of years) and a reasonable set of number ranges for the height.
>>> But then a user goes to Special:BrowseData and filters down by city, and
>>> selects a city that has only relatively short buildings, that were all
>>> built in the last 20 years. For the "Completion date" property, a simple
>>> subdivision by year would have been the better choice at this point, and
>>> for the "Height" property, all the values will wind up in the lowest
>>> number
>>> range, which makes that filter rather useless.
>>>
>>> And actually, perhaps having a "Date range" input is never an ideal
>>> option
>>> anyway - perhaps date properties should simply subdivide by whatever the
>>> best unit is for the current set of values (years, decades, centuries; or
>>> months or days), and then let the user keep subdividing after they
>>> select a
>>> value. That's how Miga does it, and it seems to work well.
>>>
>>> A similar change would be, for Text/String properties, to have the input
>>> type depend on the number of values: a "combo box" input type if the
>>> number
>>> of values is greater than some large number, like 50, vs. simply listing
>>> the set of values if it's smaller than that number. This would differ
>>> from
>>> the current situation, where again the admin has to specify ahead of time
>>> whether they want a combo box or not.
>>>
>>> My strong inclination is to switch to this approach, which would result
>>> in
>>> the removal of the special properties "Has value", "Uses time period" and
>>> "Has input type". But this would take power away from admins, so I wanted
>>> to ask before looking into this any further. Would anyone object to this
>>> sort of major change to Semantic Drilldown? Are there filter-value setups
>>> that it makes sense to keep, regardless of the current layout of the
>>> data?
>>>
>>> -Yaron
>>>
>>> --
>>> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>>>
>>> ------------------------------------------------------------------------------
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>> It's a free troubleshooting tool designed for production.
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Semediawiki-user mailing list
>>> Sem...@li...
>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>>>
>>
>>
>
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>