Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Imported_from seems to break ask-queries with SPARQL-backend #5527

Open
simontaurus opened this issue Sep 2, 2023 · 2 comments
Open

Imported_from seems to break ask-queries with SPARQL-backend #5527

simontaurus opened this issue Sep 2, 2023 · 2 comments
Labels
bug Occurrence of an unintended or unanticipated behaviour that causes a vulnerability or fatal error

Comments

@simontaurus
Copy link
Contributor

Setup

  • SMW version: 4.1.1 (also tested: 3.2.3)
  • MW version: 1.39.3 (also tested: 1.35.7)
  • PHP version: 7.4.33 (also tested: 8.1)
  • DB system (MySQL, Blazegraph, etc.) and version: MySQL 8.0.17, Blazegraph 2.1.5

Issue

[[Imported from::...]] statements seem to break ask-queries when a SPARQL-backend is used.
I asume this is due to the change from the local IRI (/id/<title>) to the imported one (e. g. foaf:Person) as primary identifier.

Steps to reproduce the observation:

  1. Create a page with an [[Imported from::foaf:Person]] statement, e. g. ImportedFromTestPage
  2. Query for that page with [[Imported_from::foaf:Person]], e. g. https://demo.open-semantic-lab.org/w/api.php?action=ask&query=[[Imported_from::foaf:Person]]
  3. Result is empty while in the sandbox instance it works as expected
@simontaurus simontaurus added the bug Occurrence of an unintended or unanticipated behaviour that causes a vulnerability or fatal error label Sep 2, 2023
@simontaurus
Copy link
Contributor Author

simontaurus commented Sep 16, 2023

Update:

The test query above works after purging the page and the iri replacement within the SPARQL query seems fine, so category:ImportedFromTestPage gets replaced with foaf:Person

But when I set the displaytitle to ImportedFromTestPageDisplayTitle with {{DISPLAYTITLE: ImportedFromTestPageDisplayTitle}}, the query https://demo.open-semantic-lab.org/w/api.php?action=ask&query=[[:Category:ImportedFromTestPage]]|?Imported_from returns

        "results": {
            "Category:ImportedFromTestPageDisplayTitle": {
                "printouts": {
                    "Imported from": []
                },
                "fulltext": "Category:ImportedFromTestPageDisplayTitle",
                "fullurl": "https://demo.open-semantic-lab.org/wiki/Category:ImportedFromTestPageDisplayTitle",
                "namespace": 14,
                "exists": "",
                "displaytitle": ""
            }
        },

so the actual title gets replaced with the display title and fulltext points to a non-existing page which leads to errors in any consumer.

Sandbox works fine:
https://sandbox.semantic-mediawiki.net/w/api.php?action=ask&query=[[Imported_from::foaf:Person]]|?Imported_from

Looking at the logs it looks like the actual title gets replaced in the SQL queries by the display title after the SPARQL query was executet:

SMW\SQLStore\EntityStore\EntityIdFinder::fetchFromTableByTitle [0.001s] db: SELECT ... WHERE smw_title = 'ImportedFromTestPage' ...
SMW\SPARQLStore\QueryEngine\ConditionBuilder ...
SMW\SQLStore\EntityStore\EntityIdFinder::fetchFromTableByTitle [0.001s] db: SELECT ... WHERE smw_title = 'ImportedFromTestPageDisplayTitle' ...

@simontaurus
Copy link
Contributor Author

simontaurus commented Sep 17, 2023

Update:

The actual errors occurs here for self-queries (e. g. [[{{FULLPAGENAME}}]] ):

rdfs:label, which holds the display title, is used as DB_KEY, resulting in an invalid dataItem. Instead swivt:page (after removing / spliting at $wgArticlePath + namespace, e. g. Category-3A) or rdfs:isDefinedBy (after removing / spliting at Special:ExportRDF/ + namespace, e. g. Category-3A) should be used.

$respositoryResult = $this->store->getConnection( 'sparql' )->select(
'?v1 ?v2',
"<$uri> rdfs:label ?v1 . <$uri> swivt:wikiNamespace ?v2",
[ 'LIMIT' => 1 ]
);
$expElements = $respositoryResult->current();
if ( $expElements !== false ) {
// ?v1
if ( isset( $expElements[0] ) ) {
$dbKey = $expElements[0]->getLexicalForm();
} else {
$dbKey = 'UNKNOWN';
}
// ?v2
if ( isset( $expElements[1] ) ) {
$namespace = strval( $expElements[1]->getLexicalForm() );
} else {
$namespace = NS_MAIN;
}
$dataItem = new DIWikiPage(
$this->getFittingDBKey( $dbKey, $namespace ),
$namespace
);

But since the ExpElement passed to matchExpElement() e. g.

{"options":null,"value":"ImportedFromTestPage#14##","_type_":"SMW\\DIWikiPage","sortkey":null,"contextReference":null,"pageLanguage":null,"id":0}

already contains correct DB_KEY and namespace, a lookup in the triplestore is maybe not needed at all.

public function matchExpElement( ExpElement $expElement ) {
$dataItem = null;
if ( !$expElement instanceof ExpResource ) {
return $dataItem;
}
$uri = $expElement->getUri();
if ( strpos( $uri, $this->wikiNamespace ) !== false ) {
$dataItem = $this->matchToWikiNamespaceUri( $uri );
} else {
// Not in wikiNamespace therefore most likely an imported URI
$dataItem = $this->matchToUnknownWikiNamespaceUri( $uri );
}
return $dataItem;
}

simontaurus added a commit to OpenSemanticLab/SemanticMediaWiki that referenced this issue Sep 17, 2023
simontaurus added a commit to OpenSemanticLab/SemanticMediaWiki that referenced this issue Sep 17, 2023
simontaurus added a commit to OpenSemanticLab/SemanticMediaWiki that referenced this issue Sep 17, 2023
simontaurus added a commit to OpenSemanticLab/SemanticMediaWiki that referenced this issue Sep 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Occurrence of an unintended or unanticipated behaviour that causes a vulnerability or fatal error
Projects
None yet
Development

No branches or pull requests

2 participants
@simontaurus and others