Menu
▾
▴
Re: [Semediawiki-user] Fwd: Enabling querying multiple sets of pages through concepts
|
From: Sergey C. <sem...@an...> - 2008-08-14 04:41:02
|
What about something like this:
{{#multilayered_semantic_map: width=600 | height=500
| concept=c1 | facet=f1 | marker=house
| concept=c2 | facet=f2 | marker=company
| concept=c3 | facet=f3 | marker=landmark
}}
On Wed, Aug 13, 2008 at 6:28 PM, Yaron Koren <ya...@gm...> wrote:
> Well, if you want it to think of it as three queries, that's fine. Maybe it
> makes sense to look at it as both one and three at the same time - sort of
> like the trinity. :)
>
> And I'd welcome any alternate proposals to try to solve this problem,
> especially if you can include a proposed syntax.
>
> -Yaron
>
>
>
> On Wed, Aug 13, 2008 at 6:05 PM, Sergey Chernyshev <
> sem...@an...> wrote:
>
>> I'm not sure if multiple-concept query is actually one query and not 3
>> queries - I don't really see what connects those three queries into one
>> result set except for just union of results.
>>
>> As for the connection - I think it makes sense to have default Facets for
>> the concept, for example - this might be a way to avoid the problem, or add
>> the syntax to do that within the #ask. Not sure if I know what I'm talking
>> about here ;)
>>
>> Sergey
>>
>>
>>
>> On Wed, Aug 13, 2008 at 4:30 PM, Yaron Koren <ya...@gm...> wrote:
>>
>>> Hi,
>>>
>>> Well, I figured such a multiple-query ability would be useful for things
>>> other than Google Maps - other mapping extensions, for instance, or Semantic
>>> Calendar, or just standard tables and lists. I also think it's cleaner to
>>> implement it through concepts than through a parser function that takes in a
>>> bunch of different queries (if that's even possible - the syntax might be a
>>> total mess; note that parser functions can't take in an array of unknown
>>> length). Having a separate "Facet" namespace is an interesting idea - it
>>> would certainly cut down on the number of concepts you needed to define -
>>> although how would you associate concepts with facets in a multiple-concept
>>> query?
>>>
>>> -Yaron
>>>
>>>
>>>
>>> On Wed, Aug 13, 2008 at 4:13 PM, Sergey Chernyshev <
>>> sem...@an...> wrote:
>>>
>>>> Sorry, sent it off the list accidentally.
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Sergey Chernyshev <sem...@an...
>>>> >
>>>> Date: Wed, Aug 13, 2008 at 4:12 PM
>>>> Subject: Re: [Semediawiki-user] Enabling querying multiple sets of pages
>>>> through concepts
>>>> To: Yaron Koren <ya...@gm...>
>>>>
>>>>
>>>> Yaron, am I understanding you correctly that what you need to do is
>>>> logically equivalent to displaying 3 different ask queries (with different
>>>> query and different display parameters) on one map?
>>>>
>>>> Maybe it makes sense to change the way complex maps are displayed -
>>>> instead of just having "googlemap" format for one query, just have different
>>>> parser function that takes multiple ask queries as parameters? What do you
>>>> think?
>>>>
>>>> In any case, as you remember, I was suggesting that in addition to
>>>> concepts, to have display parameters to also be combined into some
>>>> ("facet"?) object and concepts having such facets assigned by default or
>>>> during query time - in this case queries that use both concepts and facets
>>>> can look like this
>>>>
>>>> {{#ask:[[Concept:Workers]][[Facet:Person name with work info]]}}
>>>>
>>>> Where concept page "Concept:Workers" has
>>>>
>>>> {{#concept:[[Category:Members]][[Has work location::+]]}}
>>>>
>>>> and facet page "Facet:Person name with work info" has
>>>>
>>>> {{#facet:?Has name| ?Has work location | ?Has company}}
>>>>
>>>> Don't know if it solves your problem, but might be a good thing to
>>>> consider in this whole query/UI configuration universe.
>>>>
>>>> Sergey
>>>>
>>>>
>>>> On Mon, Aug 11, 2008 at 10:57 AM, Yaron Koren <ya...@gm...>wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I've been thinking recently about the need for getting multiple sets of
>>>>> results from a query. I recently saw a demo of an RPI research group's
>>>>> customization of Semantic Google Maps to show multiple types of points on a
>>>>> map at the same time (representing parking spots, bus stops, etc.), each
>>>>> with their own marker image. [1] They accomplished this through some
>>>>> hardcoding in the PHP code for their data types. Unfortunately, there's no
>>>>> obvious way to make this a generic solution, so that any map could show
>>>>> multiple sets of points like this; which is too bad, because the effect is
>>>>> really nice. The problem is that you can't make a "compound query", a query
>>>>> that's in some way composed of a group of other queries. This problem has
>>>>> come up before for other extensions, and it's been handled differently for
>>>>> each one:
>>>>>
>>>>> - In Semantic Layers, the other mapping extension, individual layers
>>>>> for the map can be defined, but these only show background images (like a
>>>>> street-map view and a satellite view), and you can't have different points
>>>>> associated with each one.
>>>>>
>>>>> - In Semantic Calendar, the function that displays the calendar,
>>>>> #semantic_calendar, can take in multiple queries to show different sets of
>>>>> events, but it does this in a rather hackish way, and it can't do fairly
>>>>> obvious things like showing each set of events in a different color.
>>>>>
>>>>> - In Semantic MediaWiki, there has been discussion for a long time
>>>>> about being able to combine multiple queries in different ways, but no
>>>>> proposal has been implemented yet.
>>>>>
>>>>> The basic solution seems fairly obvious to me: having a way to define a
>>>>> sub-query that also sets some of its own display information, that can then
>>>>> be used within an #ask query. Then I realized that such an entity basically
>>>>> already exists: the new "concept" type in SMW 1.2, which lets you define a
>>>>> subquery or a set of points. The only thing missing from concepts is a way
>>>>> for them to define their own display.
>>>>>
>>>>> Before I get any further, let me note that, as far as I can think of,
>>>>> there are three different types of querying on multiple data points:
>>>>>
>>>>> 1) Different sets of pages. Example: you have a group of locations, and
>>>>> you want to show them on a map, with a different marker depending on the
>>>>> type of location it is; each type can be represented by a different query,
>>>>> but the property for the actual location is the same for all of them.
>>>>>
>>>>> 2) Querying on different properties. Example: you have a set of world
>>>>> leaders, and you want to show each one on a calendar twice: once by their
>>>>> birth date, and once by their date of death, in different colors; the two
>>>>> dates are represented by different properties.
>>>>>
>>>>> 3) Displaying different information. Example: you have a simple list of
>>>>> cities, but for cities in the United States you want to show both the state
>>>>> and the country they belong to, while for other cities, you only want to
>>>>> show the country they belong to. (That one can already be done easily in
>>>>> various ways, but let's ignore that fact).
>>>>>
>>>>> An ideal solution would allow for all three types of behavior. So let's
>>>>> take an example which combines all three: imagine a wiki for some sort of
>>>>> group, in which you want to map, for each group member, both where they live
>>>>> and where they work. On top of that, you want a different marker image for
>>>>> home and work, and when someone clicks on a marker, you want the popup text
>>>>> to show just the person's name for home locations, but the person's name and
>>>>> his/her company name for work locations. Finally, you also want to show the
>>>>> organization's headquarters on the same map, using a third marker image.
>>>>>
>>>>> Here's some sample wiki code to demonstrate how this problem would be
>>>>> solved in the scheme I'm suggesting. For the first group of points, in a
>>>>> page called "Concept:Home locations", there would be the following:
>>>>>
>>>>> {{#concept:[[Category:Members]][[Has home location::+]] | ? Has
>>>>> home location}}
>>>>> [[Has map marker image::House.png]]
>>>>>
>>>>> Note that the #concept declaration now looks more like an #ask query -
>>>>> in addition to defining the query filters, it can specify the return values
>>>>> as well. The only thing that's unique to #ask queries under this scheme is a
>>>>> definition of how the data will be displayed. Also, the concept now has an
>>>>> associated "special property", "Has map marker image", that's defined by
>>>>> some mapping extension. This is already doable now, as far as I know, so
>>>>> adding it in doesn't represent a technical change.
>>>>>
>>>>> For the second set of points, in a page called "Concept:Work
>>>>> locations", there would be the following code:
>>>>>
>>>>> {{#concept:[[Category:Members]][[Has work location::+]] | ? Has
>>>>> work location | ? Has company}}
>>>>> [[Has map marker image::Building.png]]
>>>>>
>>>>> This concept declaration is much like the first one, except that it
>>>>> returns another field, for the person's company name.
>>>>>
>>>>> For the third, in a page called "Concept:Headquarters locations", there
>>>>> would be the following:
>>>>>
>>>>> {{#concept:[[Category:Places]][Has type::Headquarters]] | ? Has
>>>>> location}}
>>>>> [[Has map marker image::Organization logo.png]]
>>>>>
>>>>> Finally, you would need an addition to #ask queries so that they could
>>>>> display more than one of these concepts at a time. I'm imagining a new
>>>>> parameter, called, say "concepts=", that would take in a list of names. For
>>>>> this example, the query might look like:
>>>>>
>>>>> {{#ask:concepts=Home locations, Work locations, Headquarters |
>>>>> format=googlemap}}
>>>>>
>>>>> So this change could also have the nice side effect of making #ask
>>>>> queries simpler.
>>>>>
>>>>> One could argue that this change would break the whole idea of
>>>>> "concepts", which are supposed to have real-life meaning, representing a
>>>>> class of pages. However, you could make the case that this addition actually
>>>>> fits in with that structure: just as with classes in other data
>>>>> representations, a concept would now represent not just a collection of
>>>>> objects but also the relevant set of displayed fields for each one.
>>>>>
>>>>> One other note is that I skipped an important detail in my description:
>>>>> how those multiple return fields are handled, given that each concept can
>>>>> return a different number of fields, and in a different order. I think this
>>>>> is actually less of a problem than it may seem. Semantic Google Maps would
>>>>> already handle this fine, since it is set to just look for the first value
>>>>> of type "Geographical coordinate" that it is given for a specific page, and
>>>>> use that as its coordinate value, regardless of the property name. Any other
>>>>> mapping extension could do likewise, and any calendar extension could also
>>>>> do the same for values of type "Date", since it's rare to want to display a
>>>>> second set of coordinates for the same point, or a second date for the same
>>>>> event. For queries in which the set of properties returned has to be
>>>>> precise, like templated queries, I think it's still doable - you would need
>>>>> to insert some nonexistent property names or whatever else in certain
>>>>> concepts to get all the fields to line up, which is somewhat of a hack, but
>>>>> I think it could work.
>>>>>
>>>>> Any thoughts on this proposal? Of course, how it gets implemented, and
>>>>> who does the development work, are another story, but I wanted to put this
>>>>> out as a potential feature.
>>>>>
>>>>> -Yaron
>>>>>
>>>>> [1] http://map.rpi.edu/index.php/RPI_Map
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>> challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win great
>>>>> prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>>>> world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> Semediawiki-user mailing list
>>>>> Sem...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Chernyshev
>>>> http://www.sergeychernyshev.com/
>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Chernyshev
>>>> http://www.sergeychernyshev.com/
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win great
>>>> prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>>> world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> Semediawiki-user mailing list
>>>> Sem...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>>>>
>>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Semediawiki-user mailing list
>>> Sem...@li...
>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>>>
>>>
>>
>>
>> --
>> Sergey Chernyshev
>> http://www.sergeychernyshev.com/
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Semediawiki-user mailing list
> Sem...@li...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>
>
--
Sergey Chernyshev
http://www.sergeychernyshev.com/
|