Christian,

That should not be the case. Specifically, whenever a column corresponding to a variable in the graph-pattern is referenced (anywhere -- in the SELECT-list, or in the WHERE-clause ...) in the SELECT query (containing the SEM_MATCH invocation in the FROM clause), SEM_MATCH returns values for that column.

If you could send us the specific SEM_MATCH query that you are using, we can take a look. Also, please include the product version number (and any patches) that you are using.

Regarding SPARQL, yes, we are currently working on supporting additional SPARQL constructs in SEM_MATCH.

Thanks,
- Souri.

Christian,

Thanks for sending the details. I have reproduced the problem. It happens when the filter argument is used with the new (curly-brace) syntax and the filter condition happens to use one or more columns not in the SELECT-list. We plan to fix it and make the fix available in a future release or patchset.

The workaround I'd recommend is to put the filter condition in a WHERE clause of the SELECT query (instead of specifying the filter condition as filter argument in the SEM_MATCH invocation) as shown below (changes in bold):

SELECT id, name
FROM table (sem_match ('{?id up:name ?name . ?id up:cofactor ?cofactor}',
sem_models ('nnupenz'), NULL,
sem_aliases (sem_alias ('up', 'http://purl.uniprot.org/core/')),*null*
)) WHERE cofactor = 'Zinc';

Other possible workarounds are:
1) add the extra column in the SELECT-list as you have done, OR
2) if the resulting table must not have that extra col, then use an outer SELECT query with the intended col list:
select id,name from (SELECT id, name, cofactor FROM TABLE(SEM_MATCH(...))), OR
3) Use the original (non-curly-brace) syntax, that is, use the following as pattern argument:
'(?id up:name ?name)( ?id up:cofactor ?cofactor)'

Thanks,
- Souri.