The filter clause that can be used within SDO_RDF_MATCH has to be a filter clause that operates on columns of the table returned by SDO_RDF_MATCH - for example the column represented by the variable 'z'. (also note that if the filter clause is passed in to SDO_RDF_MATCH it would be as the next argument - it should be argument #5 not #4).

Not really. I assume id_visibility is a column in the table visibility which has the alias t1. The alias t2 is assigned to the table returned by SDO_RDF_MATCH, and this table only has columns represented by the variables in SDO_RDF_MATCH. In this example, the columns of that table would be z, z$RDFVTYP and so on (by the way, z$RDFLTYP will only apply to object literals). There will be no column id_visibility in this table.

The graph in the internal storage is associated with the triple column only. The SDO_RDF_MATCH query operates on data pointed to by the values in the triple column only. All other columns in the table are relational columns and can be used in constructs such as joins with the table that results from the SDO_RDF_MATCH query, but they are not part of the table returned by the SDO_RDF_MATCH query.

But there is not the column id_visibility in the table visibility.
Ok so can I navigate in the graphe with a parameter like as the visibility (public, private,...) ?

Example :
-- John is the father of Suzie.
INSERT INTO family_rdf_data VALUES (1,
SDO_RDF_TRIPLE_S('family', 'http://www.example.org/family/John',
'http://www.example.org/family/fatherOf','http://www.example.org/family/Suzie'),Private);
-- John is the father of Matt.
INSERT INTO family_rdf_data VALUES (2,
SDO_RDF_TRIPLE_S('family', 'http://www.example.org/family/John',
'http://www.example.org/family/fatherOf', 'http://www.example.org/family/Matt'),Public);
-- Suzie is the mother of Jack.
INSERT INTO family_rdf_data VALUES (8,
SDO_RDF_TRIPLE_S('family', 'http://www.example.org/family/Suzie',
'http://www.example.org/family/motherOf', 'http://www.example.org/family/Jack'),Public);
-- Matt is the father of Tom.
INSERT INTO family_rdf_data VALUES (9,
SDO_RDF_TRIPLE_S('family', 'http://www.example.org/family/Matt',
'http://www.example.org/family/fatherOf', 'http://www.example.org/family/Tom'),Public);

With the request (?x :grandParentOf ?y), the admin can see the result :
<http://www.example.org/family/John> <http://www.example.org/family/grandParentOf> <http://www.example.org/family/Jack>
<http://www.example.org/family/John> <http://www.example.org/family/grandParentOf> <http://www.example.org/family/Tom>

With the request (?x :grandParentOf ?y), another people can see (without the rights) :
<http://www.example.org/family/John> <http://www.example.org/family/grandParentOf> <http://www.example.org/family/Tom>

Yes, your question is very clear. You would like to have triple level security in the RDF store. And this security should extend to the inferencing - if a new triple was inferred using a private triple then the inferred triple should be private as well.

In the current release we do not support this kind of security. Our security level is currently at the model level. Security for some operations involving individual triples is possible by having an additional column in the application table (as described in your example). This column can be used by an application to distinguish between private and public triples returned by the SDO_RDF_MATCH query. But this will not help in securing inferred triples.

We are planning triple level security such as the one you describe in a future release. We are interested in hearing more such specific security requirements, so I would welcome you to write to me about your use case directly at melliyal <dot> annamalai <at> oracle <dot> com.