# Mapping local constraints to Stardog constraints after importing

**URL:** <https://community.stardog.com/t/mapping-local-constraints-to-stardog-constraints-after-importing/3400>\
**Category:** Support\
**Created:** [December 2, 2021, 8:46am UTC](https://community.stardog.com/t/mapping-local-constraints-to-stardog-constraints-after-importing/3400 "2021-12-02T08:46:37Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![TimTam](https://avatars.discourse-cdn.com/v4/letter/t/3da27b/32.png) [@TimTam](https://community.stardog.com/u/TimTam)\
**Post date:** [December 2, 2021, 8:46am UTC](https://community.stardog.com/t/mapping-local-constraints-to-stardog-constraints-after-importing/3400/1 "2021-12-02T08:46:37Z")

</div>

In a project I am working on Constraints about the architecture are defined locally as an OWL-file and loaded into the Stardog database via calling  
`addConstraints().format(RDFFormats.RDFXML).stream(reader);`  
on an ICVConnection. However, in this process the mapping of the local constraint to the constraint in the Stardog database is lost. When then calculating the violations of these constraints in the Stardog database these violations cannot be linked back to the local constraints they originated from, which I would like to have.

Is this the wrong approach to load the constraints into the database or is there any mechanism/method that would help in retaining the mapping between local and Stardog constraints?

---

<div class="post-metadata">

**Author:** ![pavel](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pavel/32/18_2.png) [@pavel](https://community.stardog.com/u/pavel)\
**Post date:** [December 3, 2021, 10:44am UTC](https://community.stardog.com/t/mapping-local-constraints-to-stardog-constraints-after-importing/3400/2 "2021-12-03T10:44:01Z")

</div>

Hi Tim,

I am not entirely sure I understand the issue. Typically retaining a mapping between some objects requires that the objects have some sort of identifier, like an IRI or something. An ICV constraint is in general a bunch of RDF triples (at least when stored in Stardog) and the standard way to identify it would be to store in a named graph with some IRI. So you can create a named graph for your constraints (or SHACL shapes), load them there, and associate that IRI with the local file name.

It's a bit unusual to store each constraint in its own NG but maybe it's sufficient to associate your local file with the NG which stores all constraints in Stardog.

Cheers,  
Pavel

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex030/uploads/stardog/original/2X/e/ed66b48a616f505106a4acde3c9cee7e6da9bc67.svg) [@system](https://community.stardog.com/u/system)\
**Post date:** [December 17, 2021, 10:44am UTC](https://community.stardog.com/t/mapping-local-constraints-to-stardog-constraints-after-importing/3400/3 "2021-12-17T10:44:08Z")

</div>

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.