Designer-to-Studio Namespace and IRI confusion

[hall00ween]

I create a model in Stardog Designer from virtualized data. When I'm ready to publish, I set the model namespace and instance data namespace in the settings:

I publish the Designer model, ensuring the IRI matches the model namespace:

The named graph matches my IRI as well:

And I publish to a specific virtual graph:

I head over to Stardog Studio to inspect the code and it doesn't appear to use the model namespace or IRI I set in the Virtual Graph mappings:

Nor the model:

While the model code includes the IRI, it only uses it as a label:

All in all, unless I am missing something (certainly possible), it doesn't seem like the model namespace or IRI settings make it into the published result. Are there alternatives or something I am missing? Thank you for the assistance.

[Laura_Firey]

Hi Jamie,

The model and data IRIs changed in a project namespace will never edit existing values in your project.

I believe the order of operations you took was (1) Build out your model and mappings, (2) Change model and data namespace, and (3) publish. The newly defined model and data namespaces defined in (2) will only affect new model concepts and new mappings -- not the existing ones. We chose this behavior to avoid changing existing IRIs that might exist in a user's graph. I would be interested in your feedback on this choice as you seem to have had a different expectation. We're always looking to improve our tools and appreciate your feedback and insights!

There's no single action that would allow you to update the IRIs within Designer in bulk.

To have the namespaces you expect, you can:

1. In Designer, edit each model concept and the identifiers used in your mappings to reflect the desired namespace.
   Example of model concept IRI editing:
   
   Example of primary identifier IRI editing:
   

   

2. In Designer, Start over in a new project, (1) set the project model and data namespaces to your desired values, (2) model/map out your project, and then (3) publish.

3. In Studio, edit the model in the Models hub in the text editor tab and mappings in the Virtual Graph hub.

Thanks,
Laura

[hall00ween]

I believe the order of operations you took was (1) Build out your model and mappings, (2) Change model and data namespace, and (3) publish.

Yep, this was the process I followed.

I would be interested in your feedback on this choice as you seem to have had a different expectation.

Stardog's logic here makes sense. I see updating the namespace in Designer as time-consuming (either I rebuild the model to change the default namespace or I go into each resource and attribute and change).

Changing the namespace in Studio seems the less time-consuming path. Do you foresee any mishaps between the updated files in Studio and the settings in Designer? For example, if I change the namespace in the Models and Virtual Graph hub files plus I update the namespace setting in Designer, will Designer maintain that update (so that in between Designer sessions the namespace setting doesn't revert back)?

Also, a question about querying a model versus the underlying virtual graph. Below are two queries where in one I point to the virtual graph and the other I point to the model. The former results in data (1), where the latter doesn't (2). The difference below is the From command. Is there something I am missing about the query?

(1)

(2)

[Laura_Firey]

I see updating the namespace in Designer as time-consuming (either I rebuild the model to change the default namespace or I go into each resource and attribute and change).

We have captured this as an area for improvement to allow bulk updates. Thank you for your feedback!

Changing the namespace in Studio seems the less time-consuming path. Do you foresee any mishaps between the updated files in Studio and the settings in Designer? For example, if I change the namespace in the Models and Virtual Graph hub files plus I update the namespace setting in Designer, will Designer maintain that update (so that in between Designer sessions the namespace setting doesn't revert back)?

I would recommend that if you do not plan to update the model and mappings through your original Designer project going forward, you use a new project. Where you first import the model you have in Studio. Designer projects are not live reflections of the model and mappings on your endpoint so your original project will have the incorrect IRIs. If you think you'll want to modify your mappings through Designer, I would recommend updating your model in Studio (as your stated preference), creating a new Designer project (updating the project namespaces) and importing the updated model, and then remapping your resources. This would allow you to modify your mappings through Designer and re-publish. Otherwise, you will need to modify your mappings through Studio.

Once a Designer namespace for a project is updated, it will keep the update between settings. But again, Designer is not a live reflection of your data model and mappings on your endpoint, so your updates in Studio will not be reflected in your original Designer project.

Also, a question about querying a model versus the underlying virtual graph. Below are two queries where in one I point to the virtual graph and the other I point to the model. The former results in data (1), where the latter doesn't (2). The difference below is the From command. Is there something I am missing about the query?

Knowledge graphs are made of composable elements. These elements at the highest level for a database are segmented into graphs. The FROM clause specifies which graphs are within your queries scope. Studio allows you to specify the scope directly in your SPARQL query or through the named graph drop down filter (layered icon next to databases, shown below).

By specifying the model graph in (2), you are limiting the scope of your query to only your model graph. Your model graph only contains your model definition, not also your mapped data.
The first query where you specify the virtual graph results in data since you have a graph with data within your query's scope. The mapping contains implicit model definitions since your mapping has to specify that instances are a specific class type and that properties such as :bsn_nm exist.

Explorer handles the above case by always including a model scope and a graph scope (can also think about graph scopes as data scopes). For instance, in the image below, I have all virtual graphs in scope and my model KG_Training_LFM.

Hope this helps!
Laura

[hall00ween]

@Laura_Firey

Once a Designer namespace for a project is updated, it will keep the update between settings. But again, Designer is not a live reflection of your data model and mappings on your endpoint, so your updates in Studio will not be reflected in your original Designer project.

Good to know, thank you.

@Laura_Firey

By specifying the model graph in (2), you are limiting the scope of your query to only your model graph. Your model graph only contains your model definition, not also your mapped data.
The first query where you specify the virtual graph results in data since you have a graph with data within your query's scope. The mapping contains implicit model definitions since your mapping has to specify that instances are a specific class type and that properties such as :bsn_nm exist.

How I interpret this (along with the information in the first part of your reply) is that I should use the Virtual Graph (i.e., SMS2 mappings for virtualized data) solely to ingest/create resources and then assemble the graph within the context of a model. This way I can use assemble the resources from the virtual graph mappings in different ways with different models. Formerly, I had the virtual graph mappings contain graph structure also (i.e., how different resources are connected to each other).

Very helpful, thank you Laura.