Q: How to connect an Ontology to a Physical model in EDG

[Tim Smith]

Hi,

I have 2 dozen ontologies that have been developed over last two years that represent the knowledge and structure in a supply chain (It is a lot of work to get them from TBC into Personal EDG (TBC)).  I am trying to link the ontologies to physical data models (relational) where the instance data resides and I'm looking for insight in how to do this most effectively in EDG.

While there are many use cases for this linkage, the base cases are:

1. User is looking to understand a knowledge domain such as Product, including what is a product, what are the attributes and relationships, and where can they find data about products.
• The user will search for the domain of interest, most likely landing on a class page with a description of the domain and the properties and relationships related to that domain.  From here, the user can discover the systems, databases, tables and columns where the data resides.
2. User knows of a column and/or table and they need to understand what is in them.  The user will start by navigating to/searching for the column of interest and then walk into the ontology to gain full understanding as needed.
   

I am looking for the best practice in establishing the linkage between the Physical Data Model and the Ontology.

As an example, consider a minimalist Product class (defined using OWL but the issues are the same with SHACL)

There is a Product DatabaseTable instance that stores the data for Products defined by Product_1.  I want to be able to say that the object of the brandCode property is stored in the Brand Code column of the Product table.  It is the same for description.

For the ingredient property, the only thing stored in the Product table is the ID of the Material.  I want the user to know that they need to join from the Product table to the Material table to find the Material details.  These relationships are shown by dotted lines in the example model drawn below.

Is there a best practice for capturing this kind of information?  Do I need to reify the property path/restriction?

Thanks,

Tim

[Ralph TQ [Gmail]]

There is a property “mapsToProperty” defined in the SCHEMA EDG Data Assets that allows you to make the mappings.

Here is how it is defined:

And here is the SHACL property constraint that makes use of it, placing the values in a property group for "Traceability":

edg:DataElement-mapsToProperty

  rdf:type sh:PropertyShape ;

  sh:path edg:mapsToProperty ;

  rdfs:isDefinedBy <http://edg.topbraid.solutions/1.0/schema/datamodels> ;

  sh:class rdf:Property ;

  sh:group edg:TraceableGroup ;

  sh:not tosh:SystemNamespaceShape ;

  sh:order 90 ;

.

On Apr 16, 2020, at 1:39 PM, Tim Smith <smith...@gmail.com> wrote:

<image.png>

[Tim Smith]

Hi Ralph,

Should edg:mapsToProperty point to the property or the property shape?  For example, in the case of a "generic" property like description that will be used across many class definitions, such that:

:Product :description "product description"  mapsTo Product Table ---> Description Column for Product (ProdDesc)

:Material :description "material description" mapsTo Material Table ---> Description Column for Material (MatDesc)

In this case, I can point both ProdDesc and MatDesc to :description using edg:mapsToProperty but if I walk from Product to the Product-Description property shape to the :description property, I won't know which column I actually need for Product vs Material.

Thanks,

Tim

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9C3DCD70-169F-40A3-A452-653506F7CA3C%40topquadrant.com.

[Ralph TQ [Gmail]]

Hi Tim,

Replies inline.

On Apr 16, 2020, at 4:11 PM, Tim Smith <smith...@gmail.com> wrote:

Hi Ralph,

Should edg:mapsToProperty point to the property or the property shape?

Right now it resolves to instances of rdf:Property

I can add another property to map to property shape. I will call it ‘egg:mapsToPropertyShape’

You can paste the following into an overlay graph (or the supplied SCHEMA graph for Data Assets:

edg:mapsToPropertyShape

  rdf:type owl:ObjectProperty ;

  rdfs:comment "Associates an asset, such as a data element, with a SHACL property shape holding an occurrence of a datatype or object property on an ontology class. The filtering of values is over the ontologies that are included by the instance of the model that is being edited." ;

  rdfs:isDefinedBy <http://edg.topbraid.solutions/1.0/schema/datamodels> ;

  rdfs:label "maps to property shape" ;

  rdfs:subPropertyOf edg:mapsTo ;

.

edg:DataElement-mapsToPropertyShape

  rdf:type sh:PropertyShape ;

  sh:path edg:mapsToPropertyShape ;

  rdfs:isDefinedBy <http://edg.topbraid.solutions/1.0/schema/datamodels> ;

  sh:class sh:PropertyShape ;

  sh:group edg:TraceableGroup ;

  sh:not tosh:SystemNamespaceShape ;

  sh:order 95 ;

.

With this approach having property shapes as named resource as opposed to blank nodes will be important.

Ralph

For example, in the case of a "generic" property like description that will be used across many class definitions, such that:

:Product :description "product description"  mapsTo Product Table ---> Description Column for Product (ProdDesc)

:Material :description "material description" mapsTo Material Table ---> Description Column for Material (MatDesc)

In this case, I can point both ProdDesc and MatDesc to :description using edg:mapsToProperty but if I walk from Product to the Product-Description property shape to the :description property, I won't know which column I actually need for Product vs Material.

Thanks,

Tim

On Thu, Apr 16, 2020 at 1:48 PM Ralph TQ [Gmail] <rhod...@topquadrant.com> wrote:

There is a property “mapsToProperty” defined in the SCHEMA EDG Data Assets that allows you to make the mappings.

Here is how it is defined:

<Screen Shot 2020-04-16 at 1.45.25 PM.png>

And here is the SHACL property constraint that makes use of it, placing the values in a property group for "Traceability":

edg:DataElement-mapsToProperty

  rdf:type sh:PropertyShape ;

  sh:path edg:mapsToProperty ;

  rdfs:isDefinedBy <http://edg.topbraid.solutions/1.0/schema/datamodels> ;

  sh:class rdf:Property ;

  sh:group edg:TraceableGroup ;

  sh:not tosh:SystemNamespaceShape ;

  sh:order 90 ;

.

On Apr 16, 2020, at 1:39 PM, Tim Smith <smith...@gmail.com> wrote:

<image.png>

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9C3DCD70-169F-40A3-A452-653506F7CA3C%40topquadrant.com.

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLAxHcigaHpTtk6h-Jn2k1E%2BHYR0NzgJyBJr_Gficqj_A%40mail.gmail.com.

[Ralph TQ [Gmail]]

Tim

You will also need to add:

edg:DataElement

  sh:property edg:DataElement-mapsToPropertyShape ;

.

[Irene Polikoff]

There are two properties edg:mapsToProperty and edg:mapsToClass that could be used. mapsToClass can be used to point from a table or a dataset to a class. So, between these two properties you would have the contextual information that is specific to a class. Thus, I do not see a need to map to the property shape. Further, the property shape for a property that is broadly used would most likely be declared for some common parent class and inherited down. It would typically not be advisable, for example, to repeat a shape for description for every class that may have a description.

Also note that unlike edg:mapsToTerm, there isn’t any special logic in EDG for automatically suggesting connections to classes or properties based on the data profiling and sampling. The suggestions currently work only for linking data assets to glossary terms. Primarily because most people have glossaries for business definitions, not formal ontologies. But the algorithm does use shape definitions.

For example:

[Ralph TQ [Gmail]]

Tim,

Having thought some more about how property shapes are inherited by subclass a mapping would only resolve to the right class if it were a leaf class.

I prefer what Irene is proposing, the combination of the class and property will ensure that a mapping is properly resolved. 

Ralph

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6C38CAF1-B7FD-4578-83E5-725C49E48EA5%40topquadrant.com.
<PastedGraphic-1.pdf>

Employee ID rule is a shape. It is an instance of edg:edg:DataValueRule which is a subclass of sh:NodeShape.

Then you can get a recommendation

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6C38CAF1-B7FD-4578-83E5-725C49E48EA5%40topquadrant.com.
<PastedGraphic-2.png>

Also, in your diagram you used a column as a value of edg:foregnKey property. Values of this property are instances of edg:ForeignKey class which is not a column. Foreign keys can be combinations of columns.

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6C38CAF1-B7FD-4578-83E5-725C49E48EA5%40topquadrant.com.
<PastedGraphic-3.png>

On Apr 16, 2020, at 4:11 PM, Tim Smith <smith...@gmail.com> wrote:

Hi Ralph,

Should edg:mapsToProperty point to the property or the property shape?  For example, in the case of a "generic" property like description that will be used across many class definitions, such that:

:Product :description "product description"  mapsTo Product Table ---> Description Column for Product (ProdDesc)

:Material :description "material description" mapsTo Material Table ---> Description Column for Material (MatDesc)

In this case, I can point both ProdDesc and MatDesc to :description using edg:mapsToProperty but if I walk from Product to the Product-Description property shape to the :description property, I won't know which column I actually need for Product vs Material.

Thanks,

Tim

On Thu, Apr 16, 2020 at 1:48 PM Ralph TQ [Gmail] <rhod...@topquadrant.com> wrote:

There is a property “mapsToProperty” defined in the SCHEMA EDG Data Assets that allows you to make the mappings.

Here is how it is defined:

<Screen Shot 2020-04-16 at 1.45.25 PM.png>

And here is the SHACL property constraint that makes use of it, placing the values in a property group for "Traceability":

edg:DataElement-mapsToProperty

  rdf:type sh:PropertyShape ;

  sh:path edg:mapsToProperty ;

  rdfs:isDefinedBy <http://edg.topbraid.solutions/1.0/schema/datamodels> ;

  sh:class rdf:Property ;

  sh:group edg:TraceableGroup ;

  sh:not tosh:SystemNamespaceShape ;

  sh:order 90 ;

.

On Apr 16, 2020, at 1:39 PM, Tim Smith <smith...@gmail.com> wrote:

<image.png>

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9C3DCD70-169F-40A3-A452-653506F7CA3C%40topquadrant.com.

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLAxHcigaHpTtk6h-Jn2k1E%2BHYR0NzgJyBJr_Gficqj_A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6C38CAF1-B7FD-4578-83E5-725C49E48EA5%40topquadrant.com.

[Tim Smith]

Hi Ralph & Irene,

Thank you for a thoughtful discussion.  That was a great insight regarding inherited property shapes.  I will implement the mapsToClass and mapsToProperty pattern.  This should enable me to provide the required user experience and to build some consistency checks.

Also, thank you for the recommendation example.  I always struggle with business term vs formal ontology.  In this case, I chose an ontology because I sometimes turn the data into triples so I can use SHACL to validate the data, try to answer business questions, etc...  It's an on-going experiment as to what to use when.  I'd really like to create a wiki-like environment where I can crowd source knowledge around the classes or instances of the ontology but that's another project for another day.

Oh, thanks for pointing out the misuse of edg:foreignKey.  I'm still learning the EDG ontologies and discovered my error when I went to implement my diagram.  Ooops :)

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1FCCBA0B-0C5C-4C10-93D9-9C2E78855632%40topquadrant.com.