On Sonntag, 30. Dezember 2007, Yaron Koren wrote: > Dan - I doubt that there will ever be both a "regex" and a "wildcard" > option in SMW's query language - that seems like overkill, and somewhat bad > design. A single such option is enough, and if it happens, behind the > scenes, to use both SQL's and PHP's pattern-matching capabilities at > different times, that should be hidden from the user. So I doubt that > there'll be a need for two different symbols (Markus, or anyone else, > correct me if I'm wrong). > > So, let me argue in favor of the "~" symbol - hopefully it's not too late > before the Sunday evening deadline. :)
There was a drastic change in the parser of MediaWiki 1.12 that has caused some delay. So deadline is moved to today ;-) > The Halo extension is a helpful one, > but it's a spinoff of SMW, and thus there's no reason why it should hamper > design decisions in SMW. That goes for all extensions that use Semantic > MediaWiki - I know, for my own part, that the extensions I've created have > to do all sorts of work to be compatible with the different versions of > SMW. That's as it should be - the spinoffs work around the main > application. From what I understand, Halo is currently not compatible with > the most recent versions of SMW anyway, so it needs to be modified anyway - > there's no need to try to ensure backwards compatibility. > > And, as you point out, that functionality in Halo might not be getting used > at all - though even if it were, that shouldn't affect how SMW is designed. OK, I am convinced. Done. Markus > > -Yaron > > On Dec 29, 2007 9:54 PM, DanTMan < [EMAIL PROTECTED]> wrote: > > ^_^ ok, I thought we escaped with a \, which isn't something that normal > > users would find easy to use. But a starting space escape is ok. > > > > I still would pick ~ as the best thing for use of REGEX and prefer a > > different operator for wild cards > > I guess the % is probably best for the wild card operator. Which brings > > me the thought of: > > > > EQ: [[property::value]] > > NEQ: [[property::!value]] > > GT: [[property::>value]] > > LT: [[property::<value]] > > WILD: [[property::%value]] (Using ? and *) > > > > Also, I propose a few more additions since they will probably have some > > good use to. > > > > GTEQ: [[property::>=value]] > > LTEQ: [[property::<=value]] > > NWILD: [[property::!%value]] (Negated wild card) > > REGEX: [[property::~value]] or perhaps [[property::~/value/i]] (/ could > > of course be replaced with !, [], etc... any valid in preg. > > NGT: [[property::#<value]] (Natural order greater than) > > NLT: [[property::#>value]] (Natural order less than) > > NGTEQ: [[property::#<=value]] (Natural order greater than or equal to) > > NLTEQ: [[property::#>=value]] (Natural order less than or equal to) > > > > Of course, the REGEX one is provided that we can fix the issue of > > colliding with Halo. > > But on note of that negated wild card. I added that one for one primary > > reason. Unlike any of the other things, you cannot negate a wild card > > with any other format. (> can be negated with <=, eq with !, and regex > > can negate things inside of it. But you can't negate a wild card) Also, > > remember to escape things so that we can use (\* and \? to use those > > literally; I could draft all the replaces needed, but I got to go do > > something first) > > As for the Natural order ones, if you don't know what those are for, > > it's things like values of "1.2.3" and "1.12.3". Using a normal > it > > thinks that "1.2.3" is greater than "1.12.3" because the third character > > is a two and the third character in the other is a 1. But a natural > > order properly distinguishes the second number as 12. PHP has functions > > for these built in and would be nice for use. > > > > ~Daniel Friesen(Dantman) of: > > -The Gaiapedia ( http://gaia.wikia.com) > > -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) > > -and Wiki-Tools.com ( http://wiki-tools.com) > > > > Markus Krötzsch wrote: > > > On Samstag, 29. Dezember 2007, DanTMan wrote: > > >> A lot of people are accustomed to the ? (single-character match) and * > > >> (multi-character match) format. It would be easy to escape the '_'s > > >> and '%'s in a match and then do a replace of ? to _ and * to %. (A > > >> little preg and \ could still easily escape those.) > > > > > > Yes, I agree to that. I think, if nobody objects, this fixes the > > > pattern syntax. So it remains to find a good symbol for the comparator. > > > > > >> I don't know about ~ though, in the languages I've used I recall ~ > > >> having something to do with regex. I'd rather save that character for > > > > in > > > > >> case we want to be able to use the REGEXP matching inside of SQL. > > >> > > >> From what I remember, I think most people with only a little insight > > >> into technical stuff, would adjust easiest to using this set: > > >> = Equals > > >> > > >> > Greater than > > >> >= Greater than or equal to > > >> > > >> < Less than or equal to > > >> ! Not > > >> * Multi-character match > > >> ? Single-character match > > >> ~ regex > > > > > > As a note: "=" is not available in parser function #ask, since it has a > > > special meaning as parameter assignment, as e.g. in "format=table". The > > > > query > > > > > is distinguished from the other parameters and print requests in #ask > > > > since > > > > > it has no = symbol and does not start on ?. > > > > > >> But I did have a thought about the @... It's not used anywhere afaik. > > >> I did make a suggestion on using a pattern to separate the comparators > > >> from the match value. It was using [[Property::comparitor::match]], > > >> but > > >> > > >> as I now remember SMW lets you use :: to specify multiple properties. > > >> However it may be a good idea if the separator was one which wouldn't > > >> cause conflicting issues with other things. > > > > > > Maybe I should remark that the comparator we chose will never block any > > > > symbol > > > > > from being used in values. You can always escape the initial comparator > > > > by > > > > > inserting an initial space (which is ignored in all values). For > > > > instance, to > > > > > look for pages with property value "<strange value>", one could write > > > > > > [[some property:: <strange value>]] > > > > > > whereas [[some property::<strange value>]] would be equivalent to > > > > > > [[some property::< strange value>]] > > > > > > which matches all values (alphabetically) smaller than "strange > > > value>". > > > > So we > > > > > can pick any comparator letter without conflicts. > > > > > >> @ is not commonly used and > > >> does provide a little bit of a way for people to understand it's use. > > > > Or > > > > >> if you want a little farther from what can actually be used in a title > > >> (To avoid clashing with things) the # is always invalid. > > >> Say, [[prop::[EMAIL PROTECTED] or [[prop::comp#match]]. So for a not > > >> [[Has > > >> value::[EMAIL PROTECTED] or [[Has value::!#Value]]. > > > > > > Basically, spaces already play the role of your proposed @ or #. > > > > > >> I'm probably droning on now... But what about finding a good separator > > >> and allowing textual names ie: EQ[=], NOT/NEQ/[!] (!= could be thought > > >> of),LT[<], GT[>], REGEX(P)[~], LIKE[%_], wildcard[*?], etc... > > > > > > Not sure whether that would be better internationally. "<" seems to be > > > > more > > > > > universally understood than "LT". > > > > > > Another remark: "::!" stands for inequality (NEQ), not for negation > > > > (NOT). It > > > > > looks for pages that have some property value unequal to the one that > > > > was > > > > > given, and it does not matter whether or not they also have some value > > > > that > > > > > is equal. So a page that is annotated with [[property::1]] and > > > [[property::2]] would match a query atom [[property::!1]]. > > > > > >> There also is the possibility of instead of a separator, using > > >> brackets > > >> > > >> to encompass a comparator. I can hardly think of many places which > > > > would > > > > >> use (NOT) at the start of a title ([[Has value::(NOT) Title]]) or, we > > >> also have the {} and [] type brackets. [] is used by external links, > > > > but > > > > >> {} is only used in multiples as a template or variable bit but never > > > > has > > > > >> use singularly, templates and values will have already been parsed out > > >> so only the singles remain, and as a bonus, { and } are illegal in > > >> titles. So [[Has value::{NOT} Title]] is guaranteed to never clash > > >> with a legal title or match you can make. If you're worried about > > >> templates and parsing issues, those can't occur when your using > > >> something like {{{1}}} as the title ([[Has value:{NOT} {{{1}}}]]) so > > >> there's no clash. The only potential class is if someone wants to use > > >> {{{comparator|EQ}}} to specify the comparator. In that case, we could > > >> easily make { EQ } valid (trim spaces), so "{ {{{comparator|EQ}}} }" > > >> would work. > > > > > > Yes, that would work too. But I am happy with our spaces (the fact that > > > initial and trailing spaces are ignored in all property values is the > > > > key to > > > > > make that work, and I think there is no harm in assuming that). > > > > > > There is, in principle, no problem with having multi-char sequences for > > > comparators, but I would prefer something that does not require > > > internationalisation. So, given that we use * and ? instead of % and _, > > > > there > > > > > are the following options: > > > > > > 1- [[property::%*substring*]] > > > 2- [[property::#*substring*]] > > > 3- [[property::~*substring*]] (clashes with Halo) > > > 4- [[property::@*substring*]] > > > 5- maybe more ... > > > > > > My order of preference would be 3, 1, 4, 2, and I opt for 1 due to the > > > > Halo > > > > > issue. Further ideas and arguments are still welcome until Sunday > > > > evening, > > > > > when we hope to release SMW 1.0. > > > > > > Cheers, > > > > > > Markus > > > > > >> But... now I'm droning a bit much... > > >> > > >> ~Daniel Friesen(Dantman) of: > > >> -The Gaiapedia ( http://gaia.wikia.com) > > >> -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG ) > > >> -and Wiki-Tools.com (http://wiki-tools.com) > > >> > > >> Markus Krötzsch wrote: > > >>> On Freitag, 28. Dezember 2007, Yaron Koren wrote: > > >>>> How about ~%substring% instead? The "~" is the symbol for pattern > > >>>> matching in Perl and some UNIX languages, and it might be a clearer > > >>>> indicator of function than "%". > > >>> > > >>> I would immediately use that, but IFRC the Halo extension has a > > > > similar > > > > >>> syntax for a custom editing-distance database function (requires > > > > modified > > > > >>> MySQL version, and probably also has significant performance issues). > > >>> > > >>> So the question is whether we want to overwrite that (assuming that > > > > this > > > > >>> particular Halo function is not used widely), or is there another > > >>> idea for doing it? Other imaginable operators on my keyboard would be > > >>> #, &, > > > > ?, > > > > >>> @ -- none really as nice as ~ ... > > >>> > > >>> Markus > > >>> > > >>>> On Dec 27, 2007 2:16 PM, Markus Krötzsch < > > >>>> [EMAIL PROTECTED]> > > > > > > wrote: > > >>>>> Thanks. I have applied the patch, and added a way of configuring > > > > this > > > > >>>>> feature: > > >>>>> the parameter $smwgQComparators gives a (|-separated) list of > > > > supported > > > > >>>>> comparators, and can be used to enable or disable any of <, >, !, > > > > and > > > > >>>>> %. By > > >>>>> default its value is '<|>|!|%'. > > >>>>> > > >>>>> In this way one can also disable ! or even <, > if these are > > > > considered > > > > >>>>> to be > > >>>>> problematic. > > >>>>> > > >>>>> I wonder whether one should use another character instead of "%" as > > > > a > > > > >>>>> wildcard > > >>>>> inside the pattern string, so that no double-% confusion can arise. > > >>>>> Would * > > >>>>> be an alternative or would it be too confusing w.r.t. the old <ask> > > >>>>> print requests? What about +? According examples (preprocessing > > > > would > > > > >>>>> in each case > > >>>>> ensure full compatibility with SQL): > > >>>>> > > >>>>> - %%substring% > > >>>>> - %*substring* > > >>>>> - %+substring+ > > >>>>> > > >>>>> Cheers > > >>>>> > > >>>>> Markus > > >>>>> > > >>>>> On Donnerstag, 20. Dezember 2007, Asheesh Laroia wrote: > > >>>>>> On Thu, 20 Dec 2007, Thomas Bleher wrote: > > >>>>>>> Yesterday I needed LIKE queries for properties, so I added it to > > > > SMW > > > > >>>>>>> (patch attached). It was surprisingly simple. > > >>>>>> > > >>>>>> This would be LIKE TOTALLY AWESOME to get in to Semantic > > >>>>>> MediaWiki. > > >>>>>> > > >>>>>> > > >>>>>> It would be great if later SMW could have Valgol support > > >>>>>> < > > >>>>>> http://www.indwes.edu/Faculty/bcupp/things/computer/VALGOL.html>. > > >>>>>> > > >>>>>> -- Asheesh. > > >>>>>> > > >>>>>> P.S. In all total like seriousness, queries with LIKE support are > > >>>>>> a > > >>>>>> > > >>>>>> good idea.... > > >>>>>> > > >>>>>> -- > > >>>>>> The star of riches is shining upon you. > > > > ----------------------------------------------------------------------- > > > > >>>>> -- > > >>>>> > > >>>>>> This SF.net email is sponsored by: Microsoft > > >>>>>> Defy all challenges. Microsoft(R) Visual Studio 2005. > > >>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > >>>>>> _______________________________________________ > > >>>>>> Semediawiki-devel mailing list > > >>>>>> Semediawiki-devel@lists.sourceforge.net > > >>>>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > >>>>> > > >>>>> -- > > >>>>> Markus Krötzsch > > >>>>> Institut AIFB, Universät Karlsruhe (TH), 76128 Karlsruhe > > >>>>> phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > > >>>>> [EMAIL PROTECTED] www http://korrekt.org > > > > ----------------------------------------------------------------------- > > > > >>>>> -- This SF.net email is sponsored by: Microsoft > > >>>>> Defy all challenges. Microsoft(R) Visual Studio 2005. > > >>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > >>>>> _______________________________________________ > > >>>>> Semediawiki-devel mailing list > > >>>>> Semediawiki-devel@lists.sourceforge.net > > >>>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > ------------------------------------------------------------------------ > > > > > > ------------------------------------------------------------------------- > > > > >>> This SF.net email is sponsored by: Microsoft > > >>> Defy all challenges. Microsoft(R) Visual Studio 2005. > > >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > > ------------------------------------------------------------------------ > > > > >>> _______________________________________________ > > >>> Semediawiki-devel mailing list > > >>> Semediawiki-devel@lists.sourceforge.net > > >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Semediawiki-devel mailing list > > Semediawiki-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Markus Krötzsch Institut AIFB, Universät Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 [EMAIL PROTECTED] www http://korrekt.org
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
