Search bar functionality unclear (1) & Attribute display (2)

(1) I am interested to learn (and explain) the functionality of the graph search bar in Stardog Explorer. Below is a simplified graph created from the tutorial (Stardog Cloud). Aside from simplicity, one big difference is the data is virtualized (across Azure and Databricks).

Below is the graph and Explorer environment:

Let's say I'm interested in any instance or attribute of 'Texas' (or anything, really, simply testing search terms). I enter (Texas, 'Texas', "Texas", and `Texas`) into the search bar and the response is the same.

Is this a product of virtualization, improper search terms, or something else?

(Just to complete the loop, I'll enter a query through the "Query" builder looking for customers with an address (having the state attribute) equal to Texas:

(2) Each class has a collection of attributes linked to it. For example, 'Customer' has cid, full_name, email, ssn, and more. Is there a way to show these attributes? Thinking aloud, it would be great to show the attributes as nodes of the graph. Alternatively, I thought right-clicking and selecting 'Details' might display the attributes but this doesn't appear to be the case (see image below).

Now, I can click on an instance and see those attributes. But, intuitively (imo), it seems reasonable to try to display these at the class level:


One additional question, let's say that I use Stardog Explorer to give me an idea of what data is available. For example, the image below shows me details about "Jannel Gawthrope".

Now that I have a sense of the data's layout, I'd like to write some more complex queries in Stardog Studio. Is there a way to see the IRI associated with a given label? For example, if I wanted the IRI for the "has address" label so that I could use that in a query. Or the IRI for an attribute associated with a class. For example, if I wanted the zip code associated with the address 0 Hudson, California.

Hi Jamie,

(1) The text based search functionality is explained in our docs here, Stardog Explorer | Stardog Documentation Latest.

Explorer text based searches are more limited when virtual graphs are within scope. We will only search using starts with and ends with against the following properties:


When no virtual graphs are in scope, we will use full-text search if enabled (across all indexes). If full-text search is not enabled, we use contains search patterns against the same properties listed above.

For your example, Texas is an attribute of the class Address. There are no results for your text-based search as Texas is not set to any of the properties we search against.

Explorer text-based searches do not require you to wrap the search in any type of quotes. We will search for IRIs when the field is wrapped in single quotes such as urn:stardog:demos:c360:customer:90.

(2) I’ll capture your suggestion for our Product team. To summarize my understanding, you would like to see attributes displayed as part of visualizations and are confused (rightfully so!) that we do not display attributes on class definition details but do for class instance details.

(Additional question) The short answer is no -- as of today, there is no way in Explorer to identify the IRIs of relationships and attributes. I’ll capture this suggestion for our Product team as well.

To see an IRI of a class definition or class instance, you can open the see details panel and use the Send to graph button in the upper right-hand corner. The search field will contain the IRI of the class definition or class instance.

To see IRIs of your full model, I would recommend using Designer. In a new project in Designer, you can import an existing model. Open a details panel by double-clicking on a model concept. To get to the details panel you will need to open a Class the attribute is defined for and then click on the attribute of interest. Once the details view is open, hover over the label to reveal a code block icon, </>, click this. The IRI will be shown below the label. The IRI can then be edited/copied.

More on modeling in Designer in our docs, Stardog Designer | Stardog Documentation Latest.


Hi Laura, thank you for the response. (Apologies for my delay in responding too.)

(1) With the text-based search in Stardog Explorer (with virtual graphs in scope), can instances of a class have different comment, label, definition values (from the list you provided, below)? Or are those solely class level features?


(2) Let's say I develop a knowledge graph from virtualized data sources in Python (e.g., I create SMS2 mapping files externally to Stardog Cloud and move them over to the endpoint via pystardog). I leave, and another develop comes to continue the work. Is there a way in Stardog cloud for the second develop to identify what the IRI values are for the classes and data/object properties? (One solution would be for the developer to review my Python code, but I'm wondering if there is a way to get the IRIs of classes and properties in Stardog Cloud but without having developed the graph in Designer).

Thank you, have a good weekend too!

Hi Jamie,

(1) Yes, class instances can have multiple values for each property listed (comments, labels, definitions, and prefLabel). It's very typical to have multiple values for some of these properties, such as Label is many times annotated with the language the label is in, e.g. "state"@en and "estado"@es. I should note that for the property the convention would be to only include one prefLabel.

(2) A common way to share frequently used IRI patterns is to use namespaces within the database. These equate a prefix to an IRI. You can set and review these in the Database hub in Studio. Otherwise, the new developer could also review existing classes and data/object properties to follow the same convention. The developer could do so in Designer by importing the model (highlighted above). Note, that the model would not have to have been developed in Designer, only imported to Designer to read the IRIs. In Stardog Cloud, a developer could also use Studio to run SPARQL queries to return instances that are of type,, and (if those conventions were used).

Excellent, thank you for the information.