EDG Integration Points

 

TopBraid EDG’s ability to import and export data gives you some batch-oriented options for using data from other systems as well as providing managed vocabulary data and metadata for use by other systems.

For more dynamic integration with other systems, EDG offers three options for developers:

  1. Using TopBraid EDG GraphQL Endpoint  – TopBraid’s GraphQL service supports all standard features of GraphQL, providing access to data stored in EDG asset collections. Read and update access is available.
  2. Integrate by using either pre-built standardized RESTFul web services provided with TopBraid EDG or by using your own services developed with TopBraid technologies: templated queries, SPARQL Web Pages and SPARQLMotion services and functions.
  3. Using TopBraid EDG SPARQL Endpoint – to query data and, optionally, to update data.

The API endpoints can be accessed by any user of TopBraid EDG.  Users will only be able to access asset collections they have access rights for.  Users will only be able make updates to the asset collections they have rights to perform updates for. All updates made through APIs will be recorded in the history of changes.

Authentication applied to EDG will also apply to the API call. Please see Server Installation and Integration#WebServiceAuthentication for more information. 

 

GraphQL endpoint

GraphQL is a query language for APIs that produces JSON objects.

In a nutshell, GraphQL users define a query string that has a similar form to the desired JSON output. These query strings, possibly together with additional input variables, do not only specify which fields shall be returned but may also include parameters to filter, sort or page through the underlying data. TopBraid EDG supports GraphQL read queries with mutations (updates). Thus, you can use GraphQL for accessing and editing data in TopBraid EDG. Please note that GraphQL mutations with more than 800 top-level fields will be rejected due to size limitations in the engine. 

For any given asset collection (RDF graph) TopBraid’s GraphQL service automatically generates a GraphQL schema that defines the types of objects and their fields that can be used in a query. Technically, this schema is based on the SHACL shapes that form the data model of most EDG asset collections. These shapes define which “views” on the underlying data gets exposed into what kinds of JSON objects.

For example, one of the shapes used by EDG asset collections defines a property  edg:name  with value type string and a maximum cardinality of 1. This gets mapped into a single-valued GraphQL field called  name of type string. All models used by EDG are already configured to generate GraphQl schemas.

If you are using the Ontology editor in EDG to built your own models that are unrelated to models already used by EDG, in order for the data based on these models be queryable using GraphQL two conditions must be met:

  1. Models need to be defined in SHACL. This means that classes should be SHACL Node Shapes in order to be queryable using GraphQL.
  2. Classes that are to be queryable with GraphQL need to be declared as public classes of some GraphQL schema. This option is available on the class form in the GraphQL section. If a class is declared as public, its subclasses are also public, unless you override this by explicitly declaring some of them public.

In the Export tab of each asset collection, you will find an interactive tutorial for using the GraphQL endpoint. Currently, there are built-in tutorial query examples for glossaries and for data asset collections. We recommend that you use a collection of one of these types to experience the tutorial. Further documentation on GraphQL is available on the TopQuarant’s GraphQL technology page and https://www.topquadrant.com/querying-topbraid-edg-with-graphql/. The easiest way to explore how to use the GraphQL web service is to use the interactive GraphiQL browser that is accessible from the Export tab, with a network traffic monitor (such as Chrome Developer Tools) open.

The GraphQL endpoint for each asset collection is available at the following URL:

http://<server>:<port>//tbl/graphql/<asset-collection-id>

An example POST request against the Northwind example data asset collection with TopBraid EDG running under TBC-ME is

http://localhost:8083/tbl/graphql/northwind

with the following exemplar HTTP request payload:

{
	"query": "databaseColumns { name }",
	"variables": (optional)
}

Set the Accept header to application/json.

The entry point into GraphQL is the top-level query object, in between the curly braces. In TopBraid you have to select the type (shape) of top-level object that you want to retrieve. For example, for a data assets collection, you may want to fetch data base tables. The internal name for these in TopBraid is edg:DatabaseTable and their name in GraphQL is a lower-cased plural form of that name, i.e. databaseTables

Like every GraphQL object, each top-level query object must have at least one field, again enclosed by curly braces. There are two built-in fields that are always available:

  • label returns a human-readable label, using the preferred language of the HTTP request if available
  • uri returns the resource identifier (URI) of the object as a string

For example, the following GraphQL query will return all concepts ordered by their preferred label. For each concept, we will see their URI, their label, the value of a notation field and the value of the type field. For the type, we will see both the URI and the name of the class:


{
concepts (orderBy: label) {
uri
label
notation
type {
uri
label
}
}
}

When ran for the Geography Taxonomy example the output would look as follows:

{
"data": {
"concepts": [
{
"uri": "http://topquadrant.com/ns/examples/geography#Abilene",
"label": "Abilene",
"notation": [],
"type": [
{
"uri": "http://topquadrant.com/ns/examples/geography#City",
"label": "City"
}
]
},
{
"uri": "http://topquadrant.com/ns/examples/geography#Abu_Dhabi",
"label": "Abu Dhabi",
"notation": [],
"type": [
{
"uri": "http://topquadrant.com/ns/examples/geography#City",
"label": "City"
}
]
},
<the rest of the concepts>
{
"uri": "http://topquadrant.com/ns/examples/geography#Zimbabwe",
"label": "Zimbabwe",
"notation": [],
"type": [
{
"uri": "http://topquadrant.com/ns/examples/geography#Country",
"label": "Country"
}
]
}
]
}
}

Filtering

Any GraphQL object field, such as those on the top-level of a query, can take parameters – name-value pairs enclosed in round braces behind the field name. So for example if your query is about database tables, use DatabaseTables (...) to specify which database tables you want to have returned.

Filtering by Property Values

The simplest type of filter is by matching specific property values. For each field that the object can take, you can specify a name-value pair where the name is the field’s name. So if your object has a field called acronym then you can write databaseTables (acronym:"PPL") { ... } to return only those instances where the acronym has exactly the given value. This is typically a very fast operation, as it can exploit existing database indices. Alternatively, use (acronym:null) to filter those instances that do not have any value for the given field (which is quite a bit slower).

In addition to the fields specific to the current object type, you can match values of uri to select exactly the one instance that has this URI, if it exists. It is however not possible to match by label. To match by display label, use something like filter:"regex($label, 'text', 'i')".

A note to the RDF geeks: GraphQL uses just a handful of datatypes such as String and Float. TopBraid’s GraphQL mapping converts between these and the RDF/XSD datatypes on the fly. While the mapping is hopefully obvious in most cases, keep in mind that we use String to represent non-numeric types including xsd:date and xsd:dateTime. URIs are mapped to the GraphQL type ID which is essentially the same as String.

Filtering by Constraints

This type of filtering uses built-in constraint types (based on a subset of SHACL) that provide a declarative language to express common kinds of conditions. These constraints are used in values of the where parameter, which must be an input object that may have name-value pairs for any of the fields of the surrounding object type. Each of these values must be another object that uses the names from the table below to specify the actual constraints. This is best explained with an example.

The currently supported constraint parameters are:

Parameter Type Condition
hasValue Same as field Object must have exactly the given value (plus maybe others)
minCount Int Object must have at least minCount values
maxCount Int Object must have at most maxCount values
minExclusive Same as field Object must have a value so that value > minExclusive
minInclusive Same as field Object must have a value so that value >= minInclusive
maxInclusive Same as field Object must have a value so that value <= maxInclusive
maxExclusive Same as field Object must have a value so that value < maxExclusive
pattern String Object must have a value that matches the given regular expression
flags String Optional flags for the pattern regex engine, such as “i” to ignore case
exists Nested object One of the values must conform to all nested constraints

From those, the exists constraint can be used to formulate conditions that walk into adjacent objects, such as to find Persons where the Address has a City with at least 1 million inhabitants.

For example, the following query over Geography Taxonomy

{
concepts (where: {prefLabel:{pattern:"Abu"}} orderBy: label) {
uri
label
notation
type {
uri
label
}
}
}

Will return

"data": {

“concepts”: [

{

“uri”: “http://topquadrant.com/ns/examples/geography#Abu_Dhabi“,

“label”: “Abu Dhabi”,

“notation”: [],

“type”: [

{

“uri”: “http://topquadrant.com/ns/examples/geography#City“,

“label”: “City”

}

]

},

{

“uri”: “http://topquadrant.com/ns/examples/geography#Abuja“,

“label”: “Abuja”,

“notation”: [],

“type”: [

{

“uri”: “http://topquadrant.com/ns/examples/geography#City“,

“label”: “City”

}

]

}

]

}

}

Filtering by Text

Each object type supports the parameter queryText that can take any search string as value, implementing a general free-text search. If present, the system will return all objects where any literal (scalar) value matches the given string.

Filtering by SPARQL Expressions

If the simple filters from the previous sections are not sufficient, you can fall back to SPARQL. Even if you are not familiar with SPARQL, this is worth exploring as the syntax for many scenarios is quite intuitive.

The parameter to use for arbitrary SPARQL expressions is filter. The values of filter must be strings that can be parsed into valid SPARQL expressions, in the syntax that is typically used in FILTER or BIND statements in SPARQL. SPARQL includes a large number of built-in functions and operators, including functions that are specific to the TopBraid platform.

In those SPARQL filter expressions certain variables have pre-defined values. For example, if your filter expression is $variance > 0.5 and you are inside of a database column object, the variable $variance will hold the value of the corresponding property (edg:variance) from that object. Note that these values are not available for multi-valued properties. In those cases, use EXISTS or NOT EXISTS in SPARQL expressions. The special variable $this points at the current object itself. The variables $uri and $label have the corresponding fields as their string values.

For advanced users, the filter parameter offers basically the full expressivity of SPARQL, including EXISTS and NOT EXISTS clauses that check against arbitrary RDF graph patterns. Take care with variable names in such complex scenarios, as they may overlap with the pre-bound variables. Using these advanced features does require knowledge of the underlying RDF data model and the available namespaces, so we do not cover those scenarios in this tutorial. See some SPARQL tutorials or the spec for more information.

Ordering

For multi-valued object fields, use the orderBy parameter if you want the results sorted. This is slower and RDF data is inherently unordered, so use this only where needed. The values of orderBy come from an enumeration of the available fields including uri and label.

The optional field orderByDesc can be set to true for descending order.

The optional field orderByExpr can be used to specify a SPARQL expression as a String. This expression is evaluated prior to sorting, with each value of the orderBy field assigned to the variable $value. For example use orderByExpr: "LCASE($value)" to implement ignore-case ordering.

Paging

Like many other GraphQL implementations, top-level query objects in TopBraid support the parameters first and skip to return partial results:

  • first is the maximum number of objects to return in a transaction
  • skip is the offset, starting with 0 by default

Aggregations

This section assumes that Enable aggregation fields has been switched on in the server configuration parameters. The features are switched off by default because they can cause schema bloat in large data models. You are encouraged to use SHACL Property Value Rules to define the kinds of aggregations that users may ask via dedicated derived fields.

TopBraid’s GraphQL implementation comes with support for common scenarios where multiple values need to be aggregated into a single value.

Counting

All multi-valued GraphQL object fields are accompanied with a _COUNT field that produces an integer value representing the number of (matching) values. For example, for a field column there is a corresponding column_COUNT field available.

The count fields (and the other aggregation types) can use any number of filters as described above, for example to only count those columns that have a specific datatype.

Concatenating Strings

All multi-valued GraphQL object fields are accompanied with a _CONCAT field that produces a string value built by concatenating strings for each value. This takes an optional parameter separator if the string should use something else than the default comma in between sub-strings. Furthermore, there is an optional argument labelExpr that transforms values on-the-fly using SPARQL expressions. For example, use labelExpr:"LCASE($value)" to produce a concatenation of lower-case strings.

There are no suitable examples for this section that work with the current Lineage Model. However, we have 1 example for Data Assets Collections, 1 example for Glossaries.

Derived Fields

This section assumes that Enable derive fields has been switched on in the server configuration parameters. The feature is switched off by default because it may give users too much expressive power that may lead to poor performance. You are encouraged to use SHACL Property Value Rules to define the kinds of derivations that users may ask.

In some cases, JSON fields should be computed on the fly. TopBraid’s GraphQL implementation supports “magic” fields that are derived using SPARQL expressions. There is one such field for the built-in datatypes: deriveBooleanderiveFloatderiveInt and deriveString. It is common to use GraphQL aliases so that the names in the generated JSON will not start with derive.

The values of these fields must be valid SPARQL expressions, and these fields can access the values of other property values similar to how SPARQL-based filter expressions work.

Updating

Data is updated using GraphQL mutations.

The following query ran over the GraphQL endpoint for the Geography Taxonomy will add a new instance of the class Country:


mutation {
createCountry (input: {
uri: “http://example.org/Utopia“,
prefLabel: { string: “Utopia” }
})
commit
}

Success response will look as follows


{
“data”: {
“createCountry”: true,
“commit”: “GraphQL mutation”
}
}

Mutations can add and modify multiple resources. For example, the following creates one new resource of type City an updates information about existing resource of type ConceptScheme. 


mutation {
createCity (input: {
uri: “http://example.org/Harmony“,
prefLabel: { string: “Harmony” }
broader: {
uri: “http://example.org/Utopia“
}
})
updateConceptScheme (input: {
uri: “http://topquadrant.com/ns/examples/geography#Geography“,
hasTopConcept: {
uri: “http://example.org/Utopia“
}
})
report {
addedCount
deletedCount
}
commit (message: “Added city and connected Utopia”)
}

 

GraphQL Additional Examples

 

GQL Querying – ASK equivalent

GQL does not have an equivalent SPARQL ASK that returns true or false it the resource or triple exists. However, this can be replicated via GQL queries.

Checking if a resource exists

There are two ways where one can either use the uri of a resource or a particular value within the same resource.

{
  cities(where:{prefLabel:{hasValue: “Birkirkara”}}){
    uri
  }
}

If a resource with the given uri or value exists, then GQL will return a populated array, whilst if not, an empty array will be returned.

{
  “data”: {
    “cities”: [
      {
        “uri”: “_:4e096e42-6c01-4db1-82ce-cefbfa6bf5fc”
      }
    ]
  }
}

GQL mutations (insert, update, delete)

For GQL queries and mutations in a particular graph, you first need to #find-home-graph, which can be done via a SPARQL query. EDG provides a dedicated Graph QL endpoint for each home graph/asset collection: http://<edg_host>/graphql/<graph_id>

For a mutation to happen, one needs to identify the resource’s type for the required write operation. Therefore, if for example we have a type g:City and we would like to create a new City in our taxonomy, then we will have a corresponding mutation function called createCity. For more information on these operations, EDG’s Graph QL endpoints provide a dedicated documentation explorer, based on the schema for the particular home graph. This is part of the endpoint’s UI.

GQL mutation – Insert

The following example creates a new g:City. If no uri is defined, EDG automatically assigns a local identifier (blank node) for the new mutation. The createCity defines the resource (or concept in taxonomies), whilst the commit operation creates the resource in the knowledge graph.

mutation{
  createCity(input: {
        prefLabel:{
      lang:”en”
      string:”Birkirkara”
    }
        broader: {
      uri:”http://topquadrant.com/ns/examples/geography#Malta”
    }
    lat: {
      datatype: “http://www.w3.org/2001/XMLSchema#double”
      string:”35.89722″
    }
    long: {
      datatype: “http://www.w3.org/2001/XMLSchema#double”
      string:”14.46111″
    }
  })
  commit
}

GQL mutation – Update

In order to update an existing resource, one needs to find the relevant uri. This can be done via a GQL query. Once the URI is known, the update mutation can be done as follows:

mutation{
  updateCity(input:{
    uri: “_:4e096e42-6c01-4db1-82ce-cefbfa6bf5fc”
    altLabel:{
      lang:”en”
      string:”B’kara”
    }
  })
  commit
}

The uri field is mandatory, whilst the rest follows the same pattern as the insert operation.

GQL mutation – Delete

Deleting also requires the uri of the resource in question.

mutation{
    delete(uri: “_:4e096e42-6c01-4db1-82ce-cefbfa6bf5fc”)
  commit
}

GQL validation

In case validation is required prior to committing to the asset collection, EDG provides a dedicated operation to run the defined concept and values through the validation mechanism. This would provide a report on the values which are failing validation (e.g. missing fields, incorrect semantic values etc…). The GQL operation is a follows:

report{
    conforms
    results {
      message
      path
      pathLabel
    }
  }

If the defined resource conforms to the validation rules, then GQL would return true, whilst any problems will be reported through the results object.

GQL preview

It is also possible to preview triples being added and/or deleted via GQL mutations. The report operation has two fields addedTurtleSourceCode and deletedTurtleSourceCode which outputs the added and deleted triples in a TURTLE string format. This can be cleaned and viewed in an external Turtle/RDF viewer. The preview does not require a commit operation.

report {
    addedTurtleSourceCode
    deletedTurtleSourceCode
}

GQL bulk mutation

Resources can be deleted in bulk. The delete operation can accept the uris argument, where it accepts a list of URIs.

mutation{
  delete(uris:[ “http://topquadrant.com/ns/examples/geography#Malta”, “http://topquadrant.com/ns/examples/geography#France”, “http://topquadrant.com/ns/examples/geography#Italy”])
  commit
}

GQL also allow us to bulk add values to a given resource and predicate:

mutation{
    addValues(resource: “http://topquadrant.com/ns/examples/geography#Malta”,
    predicate:”http://topquadrant.com/ns/examples/geography#testPredicate”,
    values: [{ lex:”a”, dt:”http://www.w3.org/2001/XMLSchema#string” }, { lex:”b”, dt:”http://www.w3.org/2001/XMLSchema#string” }]
  )
  commit
}

Similarly, bulk values can be deleted from a given resource and predicate:

deleteValues(resource: “http://topquadrant.com/ns/examples/geography#Malta”,
  predicate:”http://topquadrant.com/ns/examples/geography#testPredicate”,
  values: [{ lex:”a”, dt:”http://www.w3.org/2001/XMLSchema#string” }, { lex:”b”, dt:”http://www.w3.org/2001/XMLSchema#string” }]
)

### Finding the home graph for a particular resource > Beyond that or maybe related…do we have a service for “what is X’s home graph”? We may not need it but it would be interesting to know “where should this data be created?”.

Use a SPARQL query to find the particular resource

SELECT ?masterGraph ?graph_id
WHERE {
    () teamwork:readableGraphsUnderTeamControl (?masterGraph ?teamGraph) .
    GRAPH ?masterGraph {
        <http://topquadrant.com/ns/examples/geography#Dublin> a ?any .
    }
    BIND(teamwork:graphIdFromGraph(?masterGraph) as ?graph_id)
}

Otherwise, if you do not know the URI, you can use a particular predicate. Naturaly, this is less accurate if you use the same ontology in multiple asset collections, for example:

SELECT ?masterGraph ?graph_id
WHERE {
    () teamwork:readableGraphsUnderTeamControl (?masterGraph ?teamGraph) .
    GRAPH ?masterGraph {
        ?anyResource skos:prefLabel “Malta”@en
    }
    BIND(teamwork:graphIdFromGraph(?masterGraph) as ?graph_id)
}

Custom-defined RESTful Web Services

When a user of EDG saves a search and/or saves a SPARQL query, they are creating a service that is available not only through EDG UI, but also as an API call.

To call a saved SPARQL query as an API, navigate to the Export tab: Export > Export using Saved SPARQL Query and copy the Service URL.

To call a saved search as an API, navigate to the Export tab: Export > Export using Saved Search and copy the Service URL.

Saved queries and searches use a predefine search criteria and return predefined result fields. The only variables you can pass to a saved query service are the format of the results (e.g., XML, TSV, CSV, JSON) using &format parameter, graph to run the query against using &default-graph-uri parameter and whether the query should query the specified graph only or specified graph with all it owl:imports closure using &with-imports parameter.

Templated queries, on the other hand, let you define and use additional parameters. For example, with a saved query or a search you could return all concepts that have at least two children. With a templated query, you can define a number of children as a parameter.

Using the provided IDE, TopBraid Composer, additional web services can be developed if needed. Just as pre-built services these can be implemented as:

  • SPIN Templates from .spin. files. These are templated (parametrized) SPARQL queries.
  • SPARQLMotion scripts from .sms. files
  • SWP Services from .ui. files.

For more information on Web Services with TopBraid see http://www.topquadrant.com/2015/07/24/web-services-and-topquadrant-products/ and http://www.topquadrant.com/2013/07/01/creating-web-services-with-the-topbraid-platform/.

Detailed guide on developing using SWP is available at  SPARQL Web Pages – User Guide.

Any API that you develop using SPIN, SPARQLMotion or SWP and deploy on the EDG server will be automatically fully documented when marked as public. You will see their documentation by selecting Server Administration > Available Web Services.

Pre-built RESTful Web Services

EDG exposes a variety of common operations for use in pre-built RESTful Web Services implemented using one of the following mechanisms:

  • SPIN Templates from .spin. files. These are templated (parametrized) SPARQL queries.
  • SPARQLMotion scripts from .sms. files
  • SWP Services from .ui. files.

TopBraid includes a facility for auto-generating API documentation. This means that any API that has been developed and deployed is automatically fully documented in your installation of TopBraid EDG when marked as public. This includes pre-built TopQuadrant provided APIs as well as any customer developed APIs. The documentation is available from the Server Administration console.

Selecting Server Administration > Available Web Services displays a page that lists web services available on this server.

The following categories are currently available:

Selecting the checkbox next to any of these categories displays documentation about each of the services in the selected category(s). Service documentation will appear below the list of categories and will provide information about how to call each web service. For example: 

 

You will see parameters accepted by a service, service syntax and code that implements the service (Service Body). It will typically be a SPARQL query or SPARQL Web Pages (SWP) script.

For the SPIN (SPARQL) template services, the following values can either be supplied in the HTTP request’s Accept header or as the value of the _format argument:

Response type Format name Arguments accepted
application/sparql-results+xml SPARQL XML Results xml
application/sparql-results+json SPARQL JSON Results json
application/sparql-results+json-simple Simple JSON Format json-simple
text/csv Comma separated values csv
text/tab-separated-values Tab separated values tsv
application/rdf+xml RDF/XML application/rdf+xml
text/turtle Turtle text/turtle

 

If you do not explicitly specify the response type, defaults will be used. The default serialization of SELECT result sets is JSON, following the SPARQL protocol. When you call a service from a web browser’s address bar, the mime type will typically be requested as something that includes the string “xml”, and in this case it will produce SPARQL XML Results. CONSTRUCT queries are returned in Turtle format by default.

The value of the _base argument can be a full graph URI or a short graph name. To define short graph names, go to the Server Administration > Server Configuration Parameters page. In the section named “URI Parameters” define an instance of “Short graph names”.

  

Available Web Services List 6.3

SPARQL endpoint

SPARQL endpoints provide a programmatic interface to query RDF data using the  standardized query language SPARQL 

Using SPARQL is similar to using a public endpoint of a database where you can perform your own queries instead of having to learn and use the – often restrictive – web service APIs. All you need to know is the query language (SPARQL). Results of SELECT SPARQL queries are tabular structures. If you are interested in APIs that return nested JSON structures, consider using GraphQL endpoint. SPARQL result sets are  standardized as described in the language specification .

There is a general SPARQL endpoint in TopBraid EDG for querying any graph hosted by EDG as well as SPARQL endpoints specific to each asset collection.

The general SPARQL endpoint is available at the following URL:

http://<server>:<port>//tbl/sparql

Each asset collection is stored as a separate named graph on the server; to find a given asset collection’s graph name, mouse over its name on the EDG home screen and note the projectGraph parameter in the URL that the name links to. NOTE: The SPARQL standard treats references to non-existent graphs the same as references to empty ones, which means that incorrect graph URIs might not raise any obvious errors.

For example, if you have EDG installed at the domain name ourserver.com on port 8080, entering the following query into the TopBraid Composer SPARQL view would send a query to that endpoint requesting a list of Continent resources in the Geography vocabulary:

SELECT ?continent WHERE
{ SERVICE <http://ourserver.com:8080/edg/tbl/sparql> 
   {GRAPH <urn:x-evn-master:geo> 
 {?continent a <http://topquadrant.com/ns/examples/geography#Continent>} 
  } 
}

Instead of using a SPARQL client, such as the TBC-ME SPARQL view to send the query to the endpoint with the SERVICE keyword, you (or, more likely, an application you are building) can run the query by embedding an escaped version of it in a URL built on the endpoint URL. For example, let’s say you wanted to send the following query to the endpoint  http://ourserver.com:8080/EDG/tbl/sparql  :

SELECT ?continent WHERE
   {GRAPH <urn:x-evn-master:geo> 
 { ?continent a <http://topquadrant.com/ns/examples/geography#Continent>} 
}

You can add an escaped version as a query parameter value to the endpoint URL shown above, resulting in the following URL (split here for display, but to be treated as a single line). The best practice is to use a URL encoding function to properly format the query for HTTP:

http://ourserver.com:8080/edg/tbl/sparql?query=SELECT+?continent+WHERE+{GRAPH+<urn:x-evn-master:geo>+
{?continent+a+<http://topquadrant.com/ns/examples/geography%23Continent>}}

An option to specifying the named graph with the GRAPH keyword, you can use an endpoint specific to the asset collection you want to query.

To do so, name the graph in a default-graph-uri parameter added to the URL. For example, let’s look at this simpler query that does not mention the graph to query:

SELECT ?continent WHERE  
{?continent a <http://topquadrant.com/ns/examples/geography#Continent>}

Escaping this and adding it to the SPARQL endpoint URL with the named graph specified using the default-graph-uri parameter gives us the following URL (split here for display, but to be treated as one line):

http://ourserver.com:8080/edg/tbl/sparql?default-graph-uri=urn:x-evn-master:geo&query=SELECT+?continent+WHERE+{?continent+a+<http://topquadrant.com/ns/examples/geography%23Continent>}

For further information on these options and on ways to specify the result set format, see the TBC-ME online help at TopBraid Composer > TopBraid Live Integration > TopBraid Live SPARQL Endpoint.

SPARQL endpoint update

SPARQL Update statements can be executed on EDG project graphs. By default, SPARQL Endpoint Updates are disabled. To enable updates set the Advanced ParameterEnable SPARQL updates  to true in Server Administration > Server Configuration Parameters. Access controls are also available for SPARQL Endpoint Updates. For more information on setup for SPARQL Endpoint update, see SPARQLEndpointUpdate

SPARQL Update statements use the sparql servlet with the update parameter for specifying the SPARQL Update query. Note that the query must therefore explicitly specify a graph context to execute the update in using the GRAPH <…> syntax. An example update call is shown in the following URL:

tbl/sparql?update=INSERT{GRAPH <urn:x-evn-master:schemaexample>{< http://topbraid.org/examples/topquadrant%23TBEVN > < http://www.w3.org/2000/01/rdf-schema%23comment > "a comment"}}WHERE {}

Note this assumes a user is logged in, either via a browser or a basic authentication request. SPARQL Updates can be included in the change history by appending the user name to the end of the graph name as in the following example. The change will be added to the change graph with the currently logged in user as the creator of the change.

tbl/sparql?update=INSERT{GRAPH <urn:x-evn-master:schemaexample:Administrator>{< http://topbraid.org/examples/topquadrant%23TBEVN > < http://www.w3.org/2000/01/rdf-schema%23comment > "a second comment"}}WHERE {}

Access controls can also be defined for SPARQL Update using the Rights Management page and the SPARQLUpdateAllowGrp and SPARQLUpdateDenyGrp groups. For more information see the Rights Management document.