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.
On Thursday, 21 May 2020 11:15:51 UTC+10, Holger Knublauch wrote:
>
>
> 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
>
>
>
>
> On Tuesday, 19 May 2020 06:26:41 UTC+10, Tim Smith wrote:
>>
>> 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.
>>
>>
>> On Mon, May 18, 2020 at 2:33 PM lip vault <[email protected]> wrote:
>>
>>>
>>> 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.
>>>
>>> --
>>> 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 [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/topbraid-users/8aa4b9d6-d2b0-467e-af85-0151e6cb6b50%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/topbraid-users/8aa4b9d6-d2b0-467e-af85-0151e6cb6b50%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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 [email protected] <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/c755b108-f0b3-4941-b29e-a0a0f51421eb%40googlegroups.com
>
> <https://groups.google.com/d/msgid/topbraid-users/c755b108-f0b3-4941-b29e-a0a0f51421eb%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/342ee2ef-9bb2-4dc7-bb7f-d332869f0d2e%40googlegroups.com.
