To create new user groups in WebLogic Server:

1. Select the security realm from the listed Realms in Figure 11-4.

2. Click Users and Groups and then Groups.

3. Click New to create new RDF user groups in Weblogic as shown below:

   Figure 11-5 Creating new user groups in WebLogic Server

   

The following example creates the following two user groups:

• RDFreadUser: for guest users with just read access to application.

• RDFreadwriteUser: for users with read and write access to RDF objects.

In order to have RDF and guest users in the user groups you must first create the RDF and guest users and then assign them to their respective groups.

To create new RDF and guest users in WebLogic server:

Prerequisites: RDF and guest users groups must be available or they must be created. See Creating User Groups in WebLogic Server for creating user groups.

1. Select the security realm from the listed Realms as seen in Figure 11-4

2. Click Users and Groups tab and then Users.

3. Click New to create the RDF and guest users.

   Figure 11-7 Create new users in WebLogic Server

   

   The following example creates two new users :

   • rdfuser: user to be assigned to group with read and write privileges.

   • nonrdfuser: guest user to be assigned to group with just read privileges.

   Figure 11-8 New RFD and Guest users

   
   Description of "Figure 11-8 New RFD and Guest users"

4. Select a user name and click Groups to assign the user to a specific group.

5. Assign rdfuser to RDFreadwriteUser group.

   Figure 11-9 RDF User

   

6. Assign nonrdfuser to RDFreadUser group.

   Figure 11-10 RDF Guest User

   

In order to create a container data source for the UI , the JDBC data source must exist in the application server.

• Creating a JDBC Data Source in WebLogic Server
  
• Creating a JDBC Data Source in Tomcat
  
• Creating an Oracle Container Data Source
  

Oracle Wallet provides a simple and easy method to manage database credentials across multiple domains. It lets you update database credentials by updating the wallet instead of having to change individual data source definitions. This is accomplished by using a database connection string in the data source definition that is resolved by an entry in the wallet.

The wallet can be a simple wallet for storing the SSO and PKI files, or a cloud wallet that also contains TNS information and other files.

To create a wallet data source in the Oracle Graph Query UI application, you must create a wallet zip file that stores user credentials for each service. Ensure that the file is stored in a safe location for security reasons. The wallet files can be created using some Oracle utilities such as mkstore or orapki, or using the Oracle Wallet Manager application

Creating a Simple Wallet

The following are the steps to create a Simple Wallet:

1. Create the wallet directory:

   mkdir /tmp/wallet

2. Create the wallet files using mkstore utility. You will be prompted for a password. Save the password to the wallet:

   ${ORACLE_HOME}/bin/mkstore –wrl /tmp/wallet –create

3. Add a database connection with user credentials. The wallet service in this case will be a string with host, port, and service name information

   ${ORACLE_HOME}/bin/mkstore –wrl /tmp/wallet
         –createCredential host:port/serviceName username password

4. Zip the wallet directory to make it available for use in web application

The created Simple wallet directory will contain the cwallet.sso and ewallet.p12 files.

Creating an Oracle Cloud Wallet

The following are the steps to create a Oracle Cloud Wallet:

1. Navigate to the Autonomous Database details page.

2. Click DB Connection.

3. On the Database Connection page, select the Wallet Type.

4. Click Download.

5. Enter the password information and download the file ( default filename is Wallet_databasename.zip).

The cloud zip file contains the files displayed in Figure 11-20 . The tnsnames.ora file contains the wallet service alias names, and TCPS information. However, it does not contain the user credentials for each service. To use the wallet with the Oracle RDF Graph Query web application for creating a data source, you must store the credentials in the wallet file. Execute the following steps to add credentials to the wallet zip file:

1. Unzip the cloud wallet zip file in a temporary directory.

2. Use the service name alias in the tnsnames.ora to store credentials.

   For example, if the service name alias is db202002041627_medium:

   ${ORACLE_HOME}/bin/mkstore –wrl /tmp/cloudwallet
         –createCredential db202002041627_mediumusername
       password

3. Zip the cloud wallet files into a new zip file.

Creating a Wallet Data Source

Using the wallet zip file, you can create a Wallet data source in the Oracle RDF Graph Query web application. Click the Wallet button to display the wallet dialog, and perform the following steps:

1. Click on the upload button, and select the wallet zip file.

   The zip file gets uploaded to the server.

2. Enter the required data source name.

3. Enter the optional data source description.

4. Define the wallet service:

   • For simple wallet, enter the wallet service string stored in the wallet file.

   • For cloud wallet, select the service name from the combo box seen in Figure 11-22

     .

External data sources are connected to the RDF data store using the endpoint URL.

You can execute SPARQL queries and updates to the RDF data store using a base URL. In some cases, such as Apache Jena Fuseki, there are specific URLs based on the dataset name. For example:

• DBpedia Base URL: http://dbpedia.org/sparql

• Apache Jena Fuseki (assuming a dataset name dset):

  • Query URL: http://localhost:8080/fuseki/dset/query

  • Update URL: http://localhost:8080/fuseki/dset/update

The RDF web application issues SPARQL queries to RDF datasets. These datasets can be retrieved from provider if a get capabilities request is available. For DBpedia, there is a single base URL to be used, and therefore a default single dataset is handled in application. For Apache Jena Fuseki, there is a request that returns the available RDF datasets in server: http://localhost:8080/fuseki/$/server. Using this request, the list of available datasets can be retrieved for specific use in an application.

To create an external RDF data source:

The following figures show an example for creating a DBpedia and Apache Jena Fuseki data sources.

The data source can be selected from the list of available data sources present in the Figure 11-25.

You can execute the following semantic network actions:

• Create a semantic network.
• Delete a semantic network.
• Gather statistics for a network.
• Refresh network indexes.
• Purge values not in use.

For Oracle semantic networks, the process of importing data into a RDF model is generally done by bulk loading the RDF triples that are available on staging table.

The available actions include:

• Upload one or more RDF files into an Oracle RDF staging table. This staging table can be reused in other bulk load operations. Files with extensions .nt (N-triples), .nq (N-quads), .ttl (Turtle), and .trig (TriG) are supported for import. There is a limit of file size to be imported, which can be tuned by administrator.

  Also, zip files can be used to import multiple files at once. However, the zip file is validated first, and will be rejected if any of the following conditions occur:

  • Zip file contains directories
  • Zip entry name extension is not a known RDF format (.nt, .nq, .ttl, .trig)
  • Zip entry size or compressed size is undefined
  • Zip entry size does exceed maximum unzipped entry size
  • Inflate ratio between compressed size and file size is lower than minimum inflate ratio
  • Zip entries total size does exceed maximum unzipped total size

• Bulk load the staging table records into an Oracle RDF model.

• View the status of bulk load events.

SPARQL queries are cached data source, and they apply to Oracle data sources. The translations of the SPARQL queries into SQL expressions are cached for Oracle RDF network models. Each model can stores up to 64 different SPARQL queries translations. The Query Cache Manager dialog, allows user to browse data source network cache for queries executed in models.

You can clear cache at different levels. The following describes the cache cleared against each level:

• Data source: All network caches are cleared.
• Network: All model caches are cleared.
• Model: All cached queries for model are cleared.
• Model Cache Identifier: Selected cache identifier is cleared.

The navigator tree shows the available RDF objects for the selected data source.

• For Oracle data sources, it will contain the different concept types like models, virtual models, view models, RDF view models, rule bases, entailments, network indexes, and datatype indexes.

  Figure 11-31 RDF Objects for Oracle Data Source

  
  

  

  
  

• For endpoint RDF data sources, the RDF navigator will have a list of names representing the available RDF datasets in the RDF store.

  Figure 11-32 RDF Objects from capabilities

  
  

  

  
  
• If an external RDF data source does not have a capabilities URL, then just a default dataset is shown.

  Figure 11-33 Default RDF Object

  

To execute SPARQL queries and SPARQL updates, open the selected RDF object in the RDF objects navigator. For Oracle RDF objects, SPARQL queries are available for models (regular models, virtual models, and view models).

Different actions can be performed on the navigator tree nodes. Right-clicking on a node under RDF objects will bring the context menu options (such as Open, Rename, Analyze, Publish, Delete) for that specific node. Guest users cannot perform actions that require a write privilege.

To execute SPARQL queries and updates, open the selected RDF object in the RDF objects navigator. For Oracle RDF objects, SPARQL queries are available for regular models, virtual models, and view models.

The following figure shows the SPARQL query page, containing the graph view.

The number of results on the SPARQL query is determined by the limit parameter in SPARQL string, or by the maximum number of rows that can be fetched from server. As an administrator you can set the maximum number of rows to be fetched in the settings page.

A graph view can be displayed for the query results. On the graph view, you must map the columns for the triple values (subject, predicate, and object).

Oracle RDF models can be published as datasets which then become available through a public REST endpoint for SPARQL queries. This endpoint URL can be used directly in applications without entering credentials.

To publish an Oracle RDF model as a dataset:

1. Right click the RDF model and select Publish from the menu as shown:

   Figure 11-36 Publish Menu

   
2. Enter the Dataset name (mandatory), Description, and Default SPARQL. This default SPARQL can be overwritten on the REST request.

   Figure 11-37 Publish RDF Model

   
3. Click OK.
   The public endpoint GET URL for the dataset is displayed:

   Figure 11-38 GET URL Endpoint

   

   This URL uses the default values defined for the dataset and follows the pattern shown:

   http://${hostname}:${port_number}/orardf/api/v1/datasets/query/published/${dataset_name}?datasource=${datasource_name}

   You can override the default parameters stored in the dataset by modifying the URL to include one or more of the following parameters:

   • query: SPARQL query
   • format: output format (json, xml, csv, tsv, n-triples)
   • options: string with Oracle RDF options
   • params: JSON string with runtime parameters (timeout, fetchSize, and others)

   The following shows the general pattern of the REST request to query published datasets (assuming the context root as orardf):

   http://${hostname}:${port_number}/orardf/api/v1/datasets/query/published/${dataset_name}?datasource=${datasource_name}&query=${sparql}&format=${format}&options=${rdf_options}&params=${runtime_params}

   In order to modify the default parameters, you must open the RDF dataset definition by selecting Open from the menu options shown in the following figure or by double clicking the published dataset:

   Figure 11-39 Open an RDF Dataset Definition

   
   The RDF dataset definition for the selected published dataset opens as shown:

   Figure 11-40 RDF Dataset Definition

   

   You can update the default parameters and preview the results.

   Note:

   • RDF user with administrator privileges can update and unpublish any dataset.
   • RDF user with read and write privileges can only manage the datasets that the user created.
   • RDF user with read privileges can only query the dataset.

The JSON file for data sources stores the general attributes of a data source, including specific properties associated with data source.

The following example shows a data source JSON file with two data sources: one an Oracle container data source defined on the application server, and the other an external data source.

{
  "datasources" : [ 
   {
    "name" : "rdfuser193c",
    "type" : "DATABASE",
    "description" : "19.3 Oracle database",
    "properties" : {
      "jndiName" : "jdbc/RDFUSER193c"
    }
   },
   {
     "name" : "dbpedia",
     "type" : "ENDPOINT",
     "description" : "Dbpedia RDF data - Dbpedia.org",
      "properties" : {
         "baseUrl" : "http://dbpedia.org/sparql",
         "provider" : "Dbpedia"
       }
    }
  ]
}

The general JSON configuration file stores information related to SPARQL queries, JBDC parameters and upload parameters.

The JSON file includes the following parameters:

• Maximum SPARQL rows: defines the limit of rows to be fetched for a SPARQL query. If a query returns more than this limit, the fetching process is stopped.
• SPARQL Query Timeout: defines the time in seconds to wait for a query to complete.
• JDBC Fetch size: the fetch size parameter for JDBC queries.
• JDBC Batch size: the batch parameter for JDBC updates.
• Maximum file size to upload: the maximum file size to be uploaded into server.
• Maximum unzipped item size: the maximum size for an item in a zip file.
• Maximum unzipped total size: the size limit for all entries in a zip file.
• Maximum zip inflate multiplier: maximum allowed multiplier when inflating files.

These parameters can be updated as shown in the following figures

The Proxy JSON configuration file contains proxy information for your enterprise network.

The file includes the following parameters:

• Use proxy: flag to define if proxy parameters should be used.
• Host: proxy host value.
• Port: proxy port value.

The Logging JSON configuration file contains the logging settings. You can specify the logging level.

For Administrators and RDF users, it is also possible to load the logs for further analysis.