Improve SemTK/SPARQLgraph handling of 'List' so it is at least consistent

[cuddihyge]

Once again thanks for helping me this. I did find something – In my ontology I am using List and I know we do not handle it in SemTK.

The thing that is interesting is that while top left view below does not show “children”; the construct view puts in a placeholder “_:b0”. In the screen capture below, I had started out with just one “Function” and then I double clicked on one of the ExpNode. But maybe because of the “List” issue, the other properties of ExpNode do not show up.

I am not asking you to handle List rather that for ExpNode you might choose to ignore “List” property in construct query but show the other properties?

Thanks Abha

[cuddihyge]

Looks like there is a similar problem with "Metadata"

[cuddihyge]

There are limits to what SemTK can do here without major architectural changes. Lists are implemented as an instance with type that is a blank node subclass of List.

This creates a parameterized class List. SemTK would have to change _:b0 into a new Class: ListRestrictionsA where RestrictionsA embodies the list length restrictions.

Further the excessive use of blank nodes makes the double click on construct feature very difficult because blank nodes are not consistent across queries, so you can't expand a blank node returned by a previous click.

SemTK has attempted to not handle SADL3 lists gracefully by:

• loading all lists into the ontology as untyped List. List properties will show up in the ontology. (You must load SadlListModel.owl to see anything half meaningful)
• queries won't include a FILTER constraint on type List. The instances' types are in the triplestore are not actually List, but the blank node. This allows some returns until it gets wrapped around blank nodes.
• queries are still awkward and ingestion probably impossible.
• lists returned by construct queries will show up to an extent, but attempting to expand your way through them with double clicking will terminate at the blank node.