Content tag set - tag display fails

75 views
Skip to first unread message

robatki...@gmail.com

unread,
May 18, 2021, 9:00:00 AM5/18/21
to TopBraid Suite Users

If I use the UI to create a tagset, when I display a tagged property the error log shows a warning:

URI <http://evn.topbraidlive.org/tagger#currentContentRootClass> has no registered function factory

when I try to programmitically recreate the tagset, even though all metadata looks the same, all namespaces look the same it behaves differently - and the tag display call fails with:

Invalid SPARQL query string: Line 3, column 78: Unresolved prefixed name: tagger:currentContentRootClass.

and the tag doesnt display..

I cant find this function defined anywhere, but if I run the SPARQL query in the editor on the graph it appears happy, but shows no result

PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX doco_sop_shapes: <http://purl.org/spar/doco_sop_shapes#>
PREFIX taggershapes: <http://topbraid.org/taggershapes#>
PREFIX teamworkconstraints: <http://topbraid.org/teamworkconstraints#>

SELECT ?predicate ?predicateLabel ?object WHERE {
                    ?subject ?predicate ?object.
                    BIND (swa:propertyLabelAtClassOrShapeInGraph(?predicate, tagger:currentContentRootClass(), ?labelGraph) AS ?predicateLabel) .
                }

or even this cut down version: 

SELECT ?predicateLabel  WHERE {
                    ?subject ?predicate ?object.
                    BIND ( tagger:currentContentRootClass() AS ?predicateLabel) .
                }

has no results, but doesnt fail..

What is this expecting to find that it cannot?



Holger Knublauch

unread,
May 18, 2021, 10:44:06 PM5/18/21
to topbrai...@googlegroups.com

Hi Rob,

I cannot find the string currentContentRootClass anymore in our code base, yet I can see it was used in some older versions of taggerprojects.ui.ttlx last year. Is there a mismatch between your workspace and the version of the UI code? What version are you on?

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/2ea51bc2-2d6b-401b-91e4-7244eedb3a40n%40googlegroups.com.

robatki...@gmail.com

unread,
May 19, 2021, 12:50:47 AM5/19/21
to TopBraid Suite Users

version 6.4, and its a new workspace built under there.  I also searched but couldnt find it - yet network sniffing showed it being called... so I'm guessing its in Java code somewhere..

Given i can make it work, with just a warning, there must still be something else not quite right - I replicated the imports, metadata, namespaces etc from the CreateTaggerProjectService and AFIACT it works exactly as expected except this one glitch..

Richard Cyganiak

unread,
May 19, 2021, 8:20:44 AM5/19/21
to topbraid-users list
This function was never called from Java code, but it was called from JavaScript front-end code via the SPARQL endpoint in 6.3.x. These calls were removed in 6.4.

The call was in the workspace file teamwork.topbraidlive.org/ui/teamwork.www/build/taggerApp.bundle.js . In a 6.3 workspace, that file will contain the string currentContentRootClass. In a 6.4 workspace, it should not.

An undefined function in SPARQL is not an error, but is treated as an unbound value. So, if it's in a FILTER, the filter is treated as false, and if it's in a BIND, no value will be bound. This is a (mis?)feature of the SPARQL standard in general: Almost any query that matches the SPARQL grammar will evaluate without error. At worst it will produce no results.

Richard



robatki...@gmail.com

unread,
May 19, 2021, 8:23:52 PM5/19/21
to TopBraid Suite Users
Interesting - a brand new workspace created with 6.4 ... 

and I _do_ find this code in that js file...  

Version: 6.4.0.v20200617-1843B

notwithstanding,  the question about why it fails when I create the tagset programmatically instead of vi the UI still stands.  

I can inspect the transitive import tree of the graph I created vs the UI created one, but the actual query goes against a rdfex.org closure built using logic I can't access  - so is there a simple way to test queries independently against this? 

I guess I can post queries matching the failed call to inspect that graph's import closure - but that depends on how it was achieved in the back end - maybe it doesnt report it ?

Is there perhaps a SHACL shape I can use to validate that all the metadata needed to work as a tag set is correct? (PS - this would be a very helpful developer tool set of all the hidden contracts about metadata :-) )

Holger Knublauch

unread,
May 19, 2021, 9:06:01 PM5/19/21
to topbrai...@googlegroups.com


On 2021-05-20 10:23 am, robatki...@gmail.com wrote:
Interesting - a brand new workspace created with 6.4 ... 

and I _do_ find this code in that js file...  

Version: 6.4.0.v20200617-1843B

notwithstanding,  the question about why it fails when I create the tagset programmatically instead of vi the UI still stands.  

I can inspect the transitive import tree of the graph I created vs the UI created one, but the actual query goes against a rdfex.org closure built using logic I can't access  - so is there a simple way to test queries independently against this?

The rdfex closure (generated via ui:graphWithImports) is really the same as if you open the main graph/file in TBC and run queries. It simply means that all transitive owl:imports will be included into a MultiUnion graph.

So if you look at the tagset instance in TBC and compare it with one generated from the UI, you should notice any difference.


I guess I can post queries matching the failed call to inspect that graph's import closure - but that depends on how it was achieved in the back end - maybe it doesnt report it ?

Is there perhaps a SHACL shape I can use to validate that all the metadata needed to work as a tag set is correct? (PS - this would be a very helpful developer tool set of all the hidden contracts about metadata :-) )

Not that I know of. There is only so much we can do here. You seem to be using EDG on a rather low level and this is of course a much more error prone process than simply using the UI or the web services that the UI uses to create a new tagset. So while most of our solution is model-driven and based on triples that represent the system's state, we don't have equal infrastructure to help programmatic users from people clicking through the UI, at least not yet.

Holger


robatki...@gmail.com

unread,
May 19, 2021, 9:39:11 PM5/19/21
to TopBraid Suite Users
Thanks Holger,

that helps me continue confident I'm not re-inventing the wheel :-)

Richard Cyganiak

unread,
May 20, 2021, 10:42:00 AM5/20/21
to 'Bohms, H.M. (Michel)' via TopBraid Suite Users

Hi Rob,

On Thu, 20 May 2021 at 01:23, robatki...@gmail.com <robatki...@gmail.com> wrote:
Interesting - a brand new workspace created with 6.4 ... 

and I _do_ find this code in that js file...  

Version: 6.4.0.v20200617-1843B

That's the 6.4.0 beta.
 
notwithstanding,  the question about why it fails when I create the tagset programmatically instead of vi the UI still stands.  

Using the 6.4.0 release version should resolve the issue.

Richard


 

robatki...@gmail.com

unread,
May 21, 2021, 9:32:53 PM5/21/21
to TopBraid Suite Users

I upgraded to 7.02 and I get a similar error:

Invalid SPARQL query string: Line 5, column 34: Unresolved prefixed name: tagger:defaultTagProperty

tagger prefix is set, and this property is set for the graph 

and the query works in the SPARQL pane (with or without the Graph clause) :

SELECT DISTINCT ?predicate ?predicateLabel ?object ?subjectRootClass ?labelGraph 
                WHERE { GRAPH <urn:x-evn-master:cadastral_survey_rules_2021_clause_jurisdictional_tagging_tagset:Administrator> {
                    {
                        {
                            ?any tagger:defaultTagProperty ?predicate .
                        }
                        UNION
                        {
                            ?any tagger:tagProperty ?predicate .
                        } .
                    } .

                    ?subject ?predicate ?object.
                    BIND(spl:object(?taggerGraph, tagger:subjectRootClass) as ?subjectRootClass) .
                    BIND (swa:propertyLabelAtClassOrShapeInGraph(?predicate, ?subjectRootClass, ?labelGraph) AS ?predicateLabel) .
                }
}

so i think the issue is not the old code but something about the graph closure logic .. 

robatki...@gmail.com

unread,
May 26, 2021, 7:46:08 PM5/26/21
to TopBraid Suite Users

Still unresolved..   the question is still why would the SPARQL endpoint complain about namespaces the SPARQL tab is happy with ?

Holger Knublauch

unread,
May 26, 2021, 8:36:25 PM5/26/21
to topbrai...@googlegroups.com

Have you tried just using the full URI of that function and not rely on the prefix? Some of our code will automatically add prefixes, other code doesn't.

Holger

robatki...@gmail.com

unread,
May 26, 2021, 10:38:16 PM5/26/21
to TopBraid Suite Users
The JS for the tag display pane calls the endpoint - the latest error isnt call the function anymore on v7 - but is still the same problem - why doesnt the SPARQL endpoint work when the SPARQL panel on the asset collection does work? 

Holger Knublauch

unread,
May 26, 2021, 10:52:54 PM5/26/21
to topbrai...@googlegroups.com


On 2021-05-27 12:38 pm, robatki...@gmail.com wrote:
The JS for the tag display pane calls the endpoint - the latest error isnt call the function anymore on v7 - but is still the same problem - why doesnt the SPARQL endpoint work when the SPARQL panel on the asset collection does work?

Because the SPARQL panel is automatically inserting the extra PREFIX declarations automatically. I am not familiar with the JS code.

Holger


Rob Atkinson

unread,
May 27, 2021, 12:09:16 AM5/27/21
to topbrai...@googlegroups.com
The JS code is for Tag panel - its not customised...

You received this message because you are subscribed to a topic in the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/topbraid-users/8btcg91X9as/unsubscribe.
To unsubscribe from this group and all its topics, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/ce9d45f5-ce6c-aa4b-4e59-57dfad59dc93%40topquadrant.com.

Holger Knublauch

unread,
May 27, 2021, 2:20:16 AM5/27/21
to topbrai...@googlegroups.com

We are looking into it. Looks our code is a bit brittle there and requires certain namespaces to be declared in the target graph.

Holger

mhof...@topquadrant.com

unread,
May 27, 2021, 11:28:36 AM5/27/21
to TopBraid Suite Users
Hi Rob,

For your 7.0.2 instance would you mind validating the below prefixes are defined for your Content Tag Set?


I was only able to replicate the reported issue in 7.0.2 when the tagger prefix was not defined.
The SPARQL query in question will be adjusted for the next release to include the prefix by default to avoid the scenario where a Content Tag Set might not have these prefixes declared.


Thanks,
Matt

robatki...@gmail.com

unread,
Jun 9, 2021, 11:07:50 PM6/9/21
to TopBraid Suite Users

Sorry I missed this reply.. 

I was setting these - but unsuccessfully it seems both ways I tried:

<teamwork:createProject arg:name="{= ?name }"
                                 
                                                    <ui:setPrefix ui:namespace="{= str(&lt;http://evn.topbraidlive.org/tagger#&gt;) }" ui:prefix="tagger"/>
                                                    <ui:setPrefix ui:namespace="{= str(&lt;http://evn.topbraidlive.org/taggerprojects#&gt;) }"  ui:prefix="taggerprojects"/>


- fixed by forcing the context to be the newly created graph - i had wrongly assumed that was the case inside the createProject tag :-(
Reply all
Reply to author
Forward
0 new messages