GraphQL query against imported ontology

[Rob Atkinson]

I have tried to make the QUDT units ontology (pre-loaded) accessible via GraphQL and failed...

If I include it into a empty data graph I can traverse and inspect all the contents...

I can set the search root to be, for example Unit

I then add  statements like this to the graph root object..

  graphql:publicClass qudt:Unit ;

 teamwork:mainClass qudt:Unit ;

  teamwork:rootClass qudt:Unit ;

but the Unit class does not show up as an option the the GraphQL schema:

{ _rootTypeShapes {

  rootQueryField

} }

=>

{

  "data": {

    "_rootTypeShapes": []

  }

}

I also tried loading the file into an ontology, running OWL->SHACL then defining the graphqL public classes,  and incuding into the data graph.  Still navigable and not queryable.

even if i wanted to, I  cannot import the file - it complains about having classes defined.

And in the search panel the search class is listed, but it doesnt offer the class hierarchy and the search box is greyed out.

I also tried building the lucene indices.

What exactly is the requirement for GraphQL to be enabled? - and can anyone provide an example recipe that works to allow query for any or all of the various models available in EDG by default.

[Holger Knublauch]

Hi Rob,

is the Unit class also instance of sh:NodeShape?

Feel free to send me what you have as a TTL file and I can take a look.

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/4764465c-5296-4328-b04d-6b1f00ff9e75n%40googlegroups.com.

[Rob Atkinson]

not sure what ttl to send -  the file is TopBraid/LinkedModels/unit-v1.0.ttl  and ?I just want to know how to expose that via GraphQL - or confirm that it cannot be done for some reasone

If I create an ontology, then execute OWL 2 SHACL then it shows:

<http://qudt.org/schema/1.0/qudt#Unit>

  a owl:Class ;

  a sh:NodeShape ;

but when I include this in my data graph...

 

  owl:imports <urn:x-evn-master:qudt_schema> ;

then it doesnt show up: 

qudt:Unit

  a owl:Class ;

  qudt:informativeReference

because somehow its picked up a different namespace

 @prefix qudt: <http://qudt.org/schema/qudt/> .

now to find out why...

[Rob Atkinson]

hmm units uses:

a <http://qudt.org/schema/qudt#ElectricCurrentUnit> 

but the qudt schema it imports uses:

a <http://qudt.org/schema/1.0/qudt#ElectricCurrentUnit> 

ouch!

the other ns was an artefact of a different failed experiment importing QUDT stuff..

[Rob Atkinson]

yep fixing the namespaces in the original data files fixes it - but you have to perform quite a few gymnastics before everything is lined up :-)

[Steve Ray]

I would strongly urge you to consider migrating to QUDT version 2.1. Much has changed since 1.0. For example, all unit instances are now simply instances of the qudt:Unit class. There is no longer a class named ElectricUnitClass, mostly because it became impractical to try to manage a class hierarchy for units that "belong" to multiple overlapping disciplines/domains. So QUDT 2.1 is much simpler in structure.

I'm available for any guidance requested should you choose to migrate to 2.1

Please check qudt.org for more information, and/or our GitHub site at https://github.com/qudt/qudt-public-repo

Steve Ray

qudt.org

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/e7c3905c-b1e3-4e62-b234-35bcb0d0e89fn%40googlegroups.com.

[Rob Atkinson]

Thanks Steve,

that makes sense, particularly since the qudt and units bundled in TBC are inconsistent w.r.t. class namespaces !

The bigger question is how reference data like this should be handled in TBC and EDG - in terms of expected update strategies and recommended pathways to making things visible and usable in EDG

As a straw man I would be expecting/hoping for:

1) Reference data to include the current best practice per product release - either update if namespace unchanged or added with new namespace

2) Old versions kept as deprecated for a few release cycles if new version has unique namespace, with links to new namespace

3) All SHACL shapes necessary to use reference data out of the box available

4) A simple documented pathway to make reference data available in EDG and via GraphQL