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