OK, my conclusion now was to support the following syntax: [[property% *subs?r*]]
where ? and * represent _ and % in SQL. Some more remarks inline below. On Sonntag, 30. Dezember 2007, DanTMan 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]] Rarely needed, but already possible by using disjunctions. > NWILD: [[property::!%value]] (Negated wild card) Maybe in the future if someone really needs it. > REGEX: [[property::~value]] or perhaps [[property::~/value/i]] (/ could > of course be replaced with !, [], etc... any valid in preg. Unlikely. Regexps are very complex and not at all efficient on a DB scale (even LIKE is a problem here, which is why it is disabled by default). > 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. On "natural orders": datatypes in SMW usually come with an own "natural order" and all comparators refer to those already. Things like the version numbers you mentioned are problematic unless restricted, since they are again hard to implement on a DB level efficiently (this is of course different if the format is somehow restricted). Note that PHP implementations of comparators do not help us, since the DB must do all the comparisons. Markus > > ~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
