Data assets import fails if datatypes are declared as OWL classes

[Rob Atkinson]

We are modelling a system where datatypes themselves are modelled in OWL, but when referenced from a data asset collection these models cause import to fail:

v 6.2

File Import Failed

Import Failed. The file declares classes, properties or shapes which is not supported for this asset collection type. You should import these into an Ontology. Unsupported resources found:

This seems to be an over-aggressive enforcement of policy to separate ontologies from instances -

a) i the check should be applied to the imported data, not the include closure

b) datatypes ought to be allowed to be expressed using OWL or SHACL models

(a canonical SHACL transformation of OWL models into datatype elements would be a good thing as well! )

[Holger Knublauch]

On 30/05/2019 1:16 pm, Rob Atkinson wrote:

We are modelling a system where datatypes themselves are modelled in OWL, but when referenced from a data asset collection these models cause import to fail:

v 6.2

File Import Failed

Import Failed. The file declares classes, properties or shapes which is not supported for this asset collection type. You should import these into an Ontology. Unsupported resources found:

This seems to be an over-aggressive enforcement of policy to separate ontologies from instances -

a) i the check should be applied to the imported data, not the include closure

So are the datatypes defined in an owl:import of the RDF file that you are importing?

b) datatypes ought to be allowed to be expressed using OWL or SHACL models

Could you clarify what you mean? You can imagine there is quite a cost in trying to support multiple ways of doing the same thing.

(a canonical SHACL transformation of OWL models into datatype elements would be a good thing as well! )

Do you mean for example turning owl:withRestrictions into sh:maxExclusive, such as done by the OWL2SHACL rule set, see owl2shacl:xsdMaxExclusive2shMaxExclusive?

Holger

--
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/a9531bad-5aea-432f-8c72-fc8e63eb5308%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob Atkinson]

The project type of the include is a edg:DatatypesProjectType 

it is included at creation time of a edg:DataAssetsProjectType, not in the imported datafile (but it should be able to be included explicitly IMHO)

and so I mean

OWL (or SHACL) to edg:DatatypesProjectType

On Thursday, 30 May 2019 13:33:03 UTC+10, Holger Knublauch wrote:

On 30/05/2019 1:16 pm, Rob Atkinson wrote:

We are modelling a system where datatypes themselves are modelled in OWL, but when referenced from a data asset collection these models cause import to fail:

v 6.2

File Import Failed

Import Failed. The file declares classes, properties or shapes which is not supported for this asset collection type. You should import these into an Ontology. Unsupported resources found:

This seems to be an over-aggressive enforcement of policy to separate ontologies from instances -

a) i the check should be applied to the imported data, not the include closure

So are the datatypes defined in an owl:import of the RDF file that you are importing?

b) datatypes ought to be allowed to be expressed using OWL or SHACL models

Could you clarify what you mean? You can imagine there is quite a cost in trying to support multiple ways of doing the same thing.

(a canonical SHACL transformation of OWL models into datatype elements would be a good thing as well! )

Do you mean for example turning owl:withRestrictions into sh:maxExclusive, such as done by the OWL2SHACL rule set, see owl2shacl:xsdMaxExclusive2shMaxExclusive?

Holger

--
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 topbrai...@googlegroups.com.

[Holger Knublauch]

The EDG Datatypes collection type was designed to contain instances of edg:Datatype only, which are higher level domain classes than RDFS datatypes. If you are not using these edg:Datatypes, why not create an Ontology collection for your datatypes? Or the reverse question is why use a EDG Datatypes collection here?

Holger

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/5620b6d0-0661-47d0-a591-7122205cec3d%40googlegroups.com.

[Rob Atkinson]

using an EDG datatypes, to leverage the nice Lineagegram views of dependencies - and to integrate description of semantic components with external system descriptions..

so we want to be able to look at stuff within EDG as well as those other systems and map dependencies across boundaries.

with polymorphism (the big topic here we can discuss) i want to be able to model the same things as ontologies, shapes and "datatypes" 

not sure I fully grok "higher level domain classes" however..

regardless, i still think my original report identifies a problem - it should not be illegal for includes to specify classes, otherwise you cant back your asset collection with your own specialised data types.  (perhaps file importers could factor out classes and create ontologies automatically and include them - or even fail and point the user at a pair of services which does that and spits out the ontology and instances as separate graphs they can persist however they like..)

[Holger Knublauch]

On 30/05/2019 5:33 pm, Rob Atkinson wrote:

using an EDG datatypes, to leverage the nice Lineagegram views of dependencies - and to integrate description of semantic components with external system descriptions..

so we want to be able to look at stuff within EDG as well as those other systems and map dependencies across boundaries.

with polymorphism (the big topic here we can discuss) i want to be able to model the same things as ontologies, shapes and "datatypes"

Right, several algorithms such as our diagrams expect instances of certain classes, and relations with certain property URIs. These can be produced with transformations, e.g. via SHACL rules or path expressions. It would be a useful exercise to try out whether mappings for your use cases can be expressed using SHACL, esp sh:values. Shapes as views. Once this is established, the next step would be to decide whether to run transformation rules as batch processes, or whether they can be computed on the fly. The GraphQL engine for example does such transforms on the fly. So assuming you have

    ex:MyDatatype a rdfs:Datatype ...

and our algorithm or diagramming component expects

    ex:MyDatatype a edg:Datatype ...

then a shape could probably produce the lower structure and a future Lineagegram might fetch its data via a fixed set of GraphQL queries (where the fields get mapped to SHACL property shapes backed by the transforms but the names of the fields are hard-coded by the Lineagegram component). Ontological commitment needs to start somewhere...

Details would need to be evaluated.

not sure I fully grok "higher level domain classes" however..

"higher level" is relative. I meant RDFS/OWL vocabulary as lower level here than some EDG domain ontology. Technically these things are of course similar, but they differ in the variety of hard-coded algorithms that exist for them.

regardless, i still think my original report identifies a problem - it should not be illegal for includes to specify classes, otherwise you cant back your asset collection with your own specialised data types.  (perhaps file importers could factor out classes and create ontologies automatically and include them - or even fail and point the user at a pair of services which does that and spits out the ontology and instances as separate graphs they can persist however they like..)

You can include any Ontology that has all freedom. But not if you are inside of one of the non-ontology collections, because TopBraid needs to be able to distinguish classes from instance data so that it can keep its internal structures (e.g. caches and GraphQL schemas) reasonably up to date.

Holger

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/548e5c51-eb4a-4641-b4b4-c13c238cf0ff%40googlegroups.com.