Hello Kjetil,
For some characters, placing quoted phrase instead of a word is enough.
Say, When "Da~!@" is in quotes inside FT expression, like
?free bif:contains "'Da~!@'"
or
?free bif:contains "'Da~!@' and 'Foo*' and not 'Foo Bar' "
the free-text expression parser will extract and normalize words from
phrase and get a single DA word, "~!@" will be treated as garbage,
somewhat like whitespace. At the same time, astericks and quotes and
backslashes are supposed to be handled by an application. One can not
expect that text from user's input can be placed into query verbatim.
Re.
DESCRIBE ?resource WHERE {
?resource dct:title ?free ;
dct:subject ?var .
?var skos:prefLabel ?free .
?free bif:contains "Da*" .
},
there are two errors. First, the query will ignore all resources whose
dct:title is not equal to skos:prefLabel, that is probably not what do
you want. So you need two variables.
DESCRIBE ?resource WHERE {
?resource dct:title ?free1 ;
dct:subject ?var .
?var skos:prefLabel ?free2 .
?free2 bif:contains "Da*" .
},
that is also not what do you want.
DESCRIBE ?resource WHERE {
{ ?resource dct:title ?free .
?free bif:contains "Da*" }
UNION
{ ?resource dct:subject ?var .
?var skos:prefLabel ?free .
?free bif:contains "Da*" .
}
}
is probably somewhat better.
The extension like
DESCRIBE ?resource WHERE {
?resource bi:any-contains "Foo* and Da*" .
}
is not very convenient for mixed storage, so I'm not sure it will ever
appear in the schedule. It may be more practical to materialize some
view and create either separate graph for the materialization or a
separate predicate like sub:literals. Depending on needs of an
application, the view may store concatenations of all literals of a
subject or a list of short items or a list of concatenated literals that
are grouped by some criteria.
Best Regards,
Ivan Mikhailov,
OpenLink Software.
