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.)
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

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. @ 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::comp@match]] or [[prop::comp#match]]. So for a not [[Has value::!@Value]] or [[Has value::!#Value]].
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...
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.

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 <mak@aifb.uni-karlsruhe.de> 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
mak@aifb.uni-karlsruhe.de        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