SPARQL question: return graph where triple is defined

[lip vault]

In a SPARQL query, is there a simple way to return the graph where a triple pattern is defined?  In topbraid hovering over a restriction statement will give one a blurb of information. 

One of the statements in the blurb is the specific rdf file where the restriction is defined.  Can you do something like this in SPARQL. 

I tried it and was hoping to have all the ?g IRIs returned, but it didn't work.

SELECT DISTINCT ?s ?p ?g
WHERE{
?s rdfs:subClassOf ?p .
GRAPH ?g
{
?p a owl:Restriction .
?p owl:onProperty propertyICareAbout .
?p owl:someValuesFrom classICareAbout .
}
}

Thanks in advance, and any help appreciated.

[Tim Smith]

This is from the TBC Help page for SPARQL Property functions:

SPARQL Property Functions

• tops:statementDefinedIn

   

  • Syntax: (?subject ?predicate ?object) tops:statementDefinedIn ?baseURI
  • Description: Returns the defining ontology base URI for a given statement. The statement should exist in or be imported into the current graph.
  • Example: If ?baseURI variable is bound as a literal or a uri node:

     
    SELECT ?baseURI
    WHERE { 
    	(geotravel:Accommodation rdf:type owl:Class) tops:statementDefinedIn ?baseURI 
    } 
    		

    The above query returns the base URI of geotravel ontology.

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8aa4b9d6-d2b0-467e-af85-0151e6cb6b50%40googlegroups.com.

[Rob Atkinson]

This is a general challenge with EDG - and in the Semantic Web as a whole AFAICT

We have open world semantics, but in reality all operations are done over some graph closure. Systems make private, hidden, decisions about how to bound such graph closures. You absolutely need to understand the scope of a function or query before you can use it, and there are only hints scattered through documents as to what they may be. As a result I always dive into the code of every element to see what it does to avoid perplexing behaviours.

In this cases I believe the magic rules are:

For SPARQL queries an unbound variable in the GRAPH is interpreted as being within the scope of every graph accessible the the deployment - and by default (or always enforced) it either refuses to do this, or it throws error messages about it being slow. 

The tops: function is (?) - perhaps the current graph's import closure?

other things work on the ui:graph, or the "current query graph" or the current project graph with or without imports etc.

IMHO the metamodel for functions ought to include standardised metadata about what graphs are included and what graphs may be modified - and the long undifferentiated lists of functions and SWP elements replaced with groupings according to the scope of the function.

To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.

[Richard Cyganiak]

> On 20 May 2020, at 02:40, Rob Atkinson <robatki...@gmail.com> wrote:
>
> You absolutely need to understand the scope of a function or query before you can use it, and there are only hints scattered through documents as to what they may be. As a result I always dive into the code of every element to see what it does to avoid perplexing behaviours.

This is a good observation. Some functions, templates or elements operate on the current query graph; some on the current query graph and its imports; some on a fixed, hardcoded graph, with or without imports; some on a graph passed in as an argument, with or without imports.

> In this cases I believe the magic rules are:
> For SPARQL queries an unbound variable in the GRAPH is interpreted as being within the scope of every graph accessible the the deployment -

Correct.

> and by default (or always enforced) it either refuses to do this, or it throws error messages about it being slow.

EDG/TBC have very wide notion of what constitutes a “graph accessible in the deployment”, many are created/calculated on demand, so accessing *all* the graphs is discouraged (and also rarely what is really wanted).

> The tops: function is (?) - perhaps the current graph's import closure?

Correct, tops:statementDefinedIn considers the current query graph and all its imports, transitively.

> other things work on the ui:graph, or the "current query graph" or the current project graph with or without imports etc.
>
> IMHO the metamodel for functions ought to include standardised metadata about what graphs are included and what graphs may be modified - and the long undifferentiated lists of functions and SWP elements replaced with groupings according to the scope of the function.

Fair point. The way we document these resources doesn't have a dedicated place to put this information, so it ends up in the rdfs:comment or not at all.


Richard

[Holger Knublauch]

On 20/05/2020 11:40, Rob Atkinson wrote:

This is a general challenge with EDG - and in the Semantic Web as a whole AFAICT

We have open world semantics, but in reality all operations are done over some graph closure. Systems make private, hidden, decisions about how to bound such graph closures. You absolutely need to understand the scope of a function or query before you can use it, and there are only hints scattered through documents as to what they may be. As a result I always dive into the code of every element to see what it does to avoid perplexing behaviours.

In this cases I believe the magic rules are:

For SPARQL queries an unbound variable in the GRAPH is interpreted as being within the scope of every graph accessible the the deployment - and by default (or always enforced) it either refuses to do this, or it throws error messages about it being slow. 

The tops: function is (?) - perhaps the current graph's import closure?

other things work on the ui:graph, or the "current query graph" or the current project graph with or without imports etc.

IMHO the metamodel for functions ought to include standardised metadata about what graphs are included and what graphs may be modified - and the long undifferentiated lists of functions and SWP elements replaced with groupings according to the scope of the function.

All functions by default operate on the current imports closure. GRAPH always goes against all graphs in the dataset, and since that won't scale it is usually not a good choice, at least for now. There are a couple of "system-level" functions in our platform that do magic things that are otherwise impossible, such as looking in the sub-graphs of the current imports closure only like the tops function here.

Holger

To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/c755b108-f0b3-4941-b29e-a0a0f51421eb%40googlegroups.com.

[Rob Atkinson]

its finding and understanding those system functions that are perhaps most useful, as they do things you cant easily do otherwise.   Developers may also create their own functions - and functions to support syncing different views of derived data across different graphs is something that is suggested by the EDG design of binding UI capabilities to asset types. 

functions are not the only reusable elements either:

ui:Elements like <teamwork:createProject> have different side effects.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/c755b108-f0b3-4941-b29e-a0a0f51421eb%40googlegroups.com.