Re: [topbraid-users] Content tag set - tag display fails

[robatki...@gmail.com]

Sorry I missed this reply.. 

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

http://evn.topbraidlive.org/tagger#>;) }" 
ui:prefix="tagger"/>
http://evn.topbraidlive.org/taggerprojects#>;) 
}"  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 :-(


On Friday, 28 May 2021 at 01:28:36 UTC+10 mhof...@topquadrant.com wrote:

> Hi Rob, 
>
> For your 7.0.2 instance would you mind validating the below prefixes are 
> defined for your Content Tag Set?
>
> PREFIX tagger: 
> PREFIX taggerprojects: 
>
> 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
>
>
>
> On Thursday, May 27, 2021 at 2:20:16 AM UTC-4 Holger Knublauch wrote:
>
>> 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
>>
>>
>> On 2021-05-27 2:09 pm, Rob Atkinson wrote:
>>
>> The JS code is for Tag panel - its not customised...
>>
>> On Thu, 27 May 2021 at 12:52, Holger Knublauch  
>> wrote:
>>
>>>
>>> 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
>>>
>>>
>>>
>>> On Thursday, 27 May 2021 at 10:36:25 UTC+10 Holger Knublauch wrote:
>>>
 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


 On 2021-05-27 9:46 am, robatki...@gmail.com wrote:


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


 On Saturday, 22 May 2021 at 11:32:53 UTC+10 robatki...@gmail.com wrote:

>
> 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 
> 
>  
> {
> {
> {
> ?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 .. 
>
> On Friday, 21 May 2021 at 00:42:00 UTC+10 Richard Cyganiak wrote:
>
>>
>> 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
>>
>>
>>  
>>
>>>
>>> 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 in

Re: [topbraid-users] Content tag set - tag display fails

[mhof...@topquadrant.com]

Hi Rob, 

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

PREFIX tagger: 
PREFIX taggerprojects: 

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



On Thursday, May 27, 2021 at 2:20:16 AM UTC-4 Holger Knublauch wrote:

> 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
>
>
> On 2021-05-27 2:09 pm, Rob Atkinson wrote:
>
> The JS code is for Tag panel - its not customised...
>
> On Thu, 27 May 2021 at 12:52, Holger Knublauch  
> wrote:
>
>>
>> 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
>>
>>
>>
>> On Thursday, 27 May 2021 at 10:36:25 UTC+10 Holger Knublauch wrote:
>>
>>> 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
>>>
>>>
>>> On 2021-05-27 9:46 am, robatki...@gmail.com wrote:
>>>
>>>
>>> Still unresolved..   the question is still why would the SPARQL endpoint 
>>> complain about namespaces the SPARQL tab is happy with ? 
>>>
>>>
>>> On Saturday, 22 May 2021 at 11:32:53 UTC+10 robatki...@gmail.com wrote:
>>>

 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 
 
  
 {
 {
 {
 ?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 .. 

 On Friday, 21 May 2021 at 00:42:00 UTC+10 Richard Cyganiak wrote:

>
> 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
>
>
>  
>
>>
>> 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 
>> :-) )
>>
>> On Wednesday, 19 May 2021 at 22:20:44 UTC+10 Richard Cyganiak wrote:
>>
>>> 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 remo

Re: [topbraid-users] Content tag set - tag display fails

[Holger Knublauch]

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


On 2021-05-27 2:09 pm, Rob Atkinson wrote:

The JS code is for Tag panel - its not customised...

On Thu, 27 May 2021 at 12:52, Holger Knublauch > wrote:



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




On Thursday, 27 May 2021 at 10:36:25 UTC+10 Holger Knublauch wrote:

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


On 2021-05-27 9:46 am, robatki...@gmail.com wrote:


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


On Saturday, 22 May 2021 at 11:32:53 UTC+10
robatki...@gmail.com wrote:


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


{
                    {
                        {
                            ?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 ..

On Friday, 21 May 2021 at 00:42:00 UTC+10 Richard
Cyganiak wrote:


Hi Rob,

On Thu, 20 May 2021 at 01:23, 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



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 :-) )

On Wednesday, 19 May 2021 at 22:20:44 UTC+10
Richard Cyganiak wrote:

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.

Re: [topbraid-users] Content tag set - tag display fails

[Rob Atkinson]

The JS code is for Tag panel - its not customised...

On Thu, 27 May 2021 at 12:52, Holger Knublauch 
wrote:

>
> 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
>
>
>
> On Thursday, 27 May 2021 at 10:36:25 UTC+10 Holger Knublauch wrote:
>
>> 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
>>
>>
>> On 2021-05-27 9:46 am, robatki...@gmail.com wrote:
>>
>>
>> Still unresolved..   the question is still why would the SPARQL endpoint
>> complain about namespaces the SPARQL tab is happy with ?
>>
>>
>> On Saturday, 22 May 2021 at 11:32:53 UTC+10 robatki...@gmail.com wrote:
>>
>>>
>>> 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
>>> 
>>> {
>>> {
>>> {
>>> ?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 ..
>>>
>>> On Friday, 21 May 2021 at 00:42:00 UTC+10 Richard Cyganiak wrote:
>>>

 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




>
> 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 :-) 
> )
>
> On Wednesday, 19 May 2021 at 22:20:44 UTC+10 Richard Cyganiak wrote:
>
>> 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
>>
>>
>>
>> On 19 May 2021, at 05:50, robatki...@gmail.com 
>> wrote:
>>
>>
>> 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 Ja

Re: [topbraid-users] Content tag set - tag display fails

[Holger Knublauch]

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




On Thursday, 27 May 2021 at 10:36:25 UTC+10 Holger Knublauch wrote:

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


On 2021-05-27 9:46 am, robatki...@gmail.com wrote:


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


On Saturday, 22 May 2021 at 11:32:53 UTC+10 robatki...@gmail.com
wrote:


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


{
                    {
                        {
                            ?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 ..

On Friday, 21 May 2021 at 00:42:00 UTC+10 Richard Cyganiak wrote:


Hi Rob,

On Thu, 20 May 2021 at 01:23, 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



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 :-) )

On Wednesday, 19 May 2021 at 22:20:44 UTC+10 Richard
Cyganiak wrote:

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 que

Re: [topbraid-users] Content tag set - tag display fails

[robatki...@gmail.com]

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? 

On Thursday, 27 May 2021 at 10:36:25 UTC+10 Holger Knublauch wrote:

> 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
>
>
> On 2021-05-27 9:46 am, robatki...@gmail.com wrote:
>
>
> Still unresolved..   the question is still why would the SPARQL endpoint 
> complain about namespaces the SPARQL tab is happy with ? 
>
>
> On Saturday, 22 May 2021 at 11:32:53 UTC+10 robatki...@gmail.com wrote:
>
>>
>> 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 
>> 
>>  
>> {
>> {
>> {
>> ?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 .. 
>>
>> On Friday, 21 May 2021 at 00:42:00 UTC+10 Richard Cyganiak wrote:
>>
>>>
>>> Hi Rob,
>>>
>>> On Thu, 20 May 2021 at 01:23, 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
>>>
>>>
>>>  
>>>

 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 :-) )

 On Wednesday, 19 May 2021 at 22:20:44 UTC+10 Richard Cyganiak wrote:

> 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
>
>
>
> On 19 May 2021, at 05:50, robatki...@gmail.com  
> wrote:
>
>
> 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..
>
> On Wednesday, 19 May 2021 at 12:44:06 UTC+10 Holger Knublauch wrote:
>
>> Hi Rob,
>>
>> I cannot fi

Re: [topbraid-users] Content tag set - tag display fails

[Holger Knublauch]

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


On 2021-05-27 9:46 am, robatki...@gmail.com wrote:


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



On Saturday, 22 May 2021 at 11:32:53 UTC+10 robatki...@gmail.com wrote:


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


{
                    {
                        {
                            ?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 ..

On Friday, 21 May 2021 at 00:42:00 UTC+10 Richard Cyganiak wrote:


Hi Rob,

On Thu, 20 May 2021 at 01:23, 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



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 :-) )

On Wednesday, 19 May 2021 at 22:20:44 UTC+10 Richard
Cyganiak wrote:

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




On 19 May 2021, at 05:50, robatki...@gmail.com
  wrote:


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

Re: [topbraid-users] Content tag set - tag display fails

[robatki...@gmail.com]

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


On Saturday, 22 May 2021 at 11:32:53 UTC+10 robatki...@gmail.com wrote:

>
> 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 
> 
>  
> {
> {
> {
> ?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 .. 
>
> On Friday, 21 May 2021 at 00:42:00 UTC+10 Richard Cyganiak wrote:
>
>>
>> Hi Rob,
>>
>> On Thu, 20 May 2021 at 01:23, 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
>>
>>
>>  
>>
>>>
>>> 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 :-) )
>>>
>>> On Wednesday, 19 May 2021 at 22:20:44 UTC+10 Richard Cyganiak wrote:
>>>
 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



 On 19 May 2021, at 05:50, robatki...@gmail.com  
 wrote:


 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..

 On Wednesday, 19 May 2021 at 12:44:06 UTC+10 Holger Knublauch wrote:

> 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
>
>
> On 2021-05-18 11:00 pm, robatki...@gmail.com wrote:
>
>
> If I use the UI to create a tagset, when I display a tagged property 
> the error log shows a warning:
>
> URI  
>  has no 
> registered function factory
>
> wh

Re: [topbraid-users] Content tag set - tag display fails

[robatki...@gmail.com]

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 

 
{
{
{
?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 .. 

On Friday, 21 May 2021 at 00:42:00 UTC+10 Richard Cyganiak wrote:

>
> Hi Rob,
>
> On Thu, 20 May 2021 at 01:23, 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
>
>
>  
>
>>
>> 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 :-) )
>>
>> On Wednesday, 19 May 2021 at 22:20:44 UTC+10 Richard Cyganiak wrote:
>>
>>> 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
>>>
>>>
>>>
>>> On 19 May 2021, at 05:50, robatki...@gmail.com  
>>> wrote:
>>>
>>>
>>> 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..
>>>
>>> On Wednesday, 19 May 2021 at 12:44:06 UTC+10 Holger Knublauch wrote:
>>>
 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


 On 2021-05-18 11:00 pm, robatki...@gmail.com wrote:


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

 URI  
  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 thi

Re: [topbraid-users] Content tag set - tag display fails

[Richard Cyganiak]

Hi Rob,

On Thu, 20 May 2021 at 01:23, 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




>
> 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 :-) )
>
> On Wednesday, 19 May 2021 at 22:20:44 UTC+10 Richard Cyganiak wrote:
>
>> 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
>>
>>
>>
>> On 19 May 2021, at 05:50, robatki...@gmail.com 
>> wrote:
>>
>>
>> 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..
>>
>> On Wednesday, 19 May 2021 at 12:44:06 UTC+10 Holger Knublauch wrote:
>>
>>> 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
>>>
>>>
>>> On 2021-05-18 11:00 pm, robatki...@gmail.com wrote:
>>>
>>>
>>> If I use the UI to create a tagset, when I display a tagged property the
>>> error log shows a warning:
>>>
>>> URI 
>>>  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 arg:  
>>> PREFIX dash:  
>>> PREFIX dc: 
>>> 
>>> PREFIX dcterms:  
>>> PREFIX defn: 
>>> 
>>> PREFIX deo:  
>>> PREFIX doco_sop_shapes: 
>>> 
>>> PREFIX edg: 
>>> 
>>> PREFIX graphql: 
>>> 
>>> PREFIX imported: 
>>> 
>>> PREFIX metadata: 
>>> 
>>> PREFIX orb:  
>>> PREFIX owl2xml: 
>>> 
>>> PREFIX owl: 
>>> 

Re: [topbraid-users] Content tag set - tag display fails

[robatki...@gmail.com]

Thanks Holger,

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


On Thursday, 20 May 2021 at 11:06:01 UTC+10 Holger Knublauch wrote:

>
> 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
>
>
>
> On Wednesday, 19 May 2021 at 22:20:44 UTC+10 Richard Cyganiak wrote:
>
>> 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
>>
>>
>>
>> On 19 May 2021, at 05:50, robatki...@gmail.com  
>> wrote:
>>
>>
>> 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..
>>
>> On Wednesday, 19 May 2021 at 12:44:06 UTC+10 Holger Knublauch wrote:
>>
>>> 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
>>>
>>>
>>> On 2021-05-18 11:00 pm, robatki...@gmail.com wrote:
>>>
>>>
>>> If I use the UI to create a tagset, when I display a tagged property the 
>>> error log shows a warning:
>>>
>>> URI  
>>>  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 arg:  
>>> PREFIX dash:  
>>> PREFIX dc:  
>>> 
>>> PREFIX dcterms: 

Re: [topbraid-users] Content tag set - tag display fails

[Holger Knublauch]

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




On Wednesday, 19 May 2021 at 22:20:44 UTC+10 Richard Cyganiak wrote:

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




On 19 May 2021, at 05:50, robatki...@gmail.com 
 wrote:


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..

On Wednesday, 19 May 2021 at 12:44:06 UTC+10 Holger Knublauch wrote:

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


On 2021-05-18 11:00 pm, robatki...@gmail.com wrote:


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

URI


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 arg:  
PREFIX dash: 

PREFIX dc: 

PREFIX dcterms: 

Re: [topbraid-users] Content tag set - tag display fails

[robatki...@gmail.com]

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 :-) )

On Wednesday, 19 May 2021 at 22:20:44 UTC+10 Richard Cyganiak wrote:

> 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
>
>
>
> On 19 May 2021, at 05:50, robatki...@gmail.com  
> wrote:
>
>
> 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..
>
> On Wednesday, 19 May 2021 at 12:44:06 UTC+10 Holger Knublauch wrote:
>
>> 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
>>
>>
>> On 2021-05-18 11:00 pm, robatki...@gmail.com wrote:
>>
>>
>> If I use the UI to create a tagset, when I display a tagged property the 
>> error log shows a warning:
>>
>> URI  
>>  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 arg:  
>> PREFIX dash:  
>> PREFIX dc:  
>> 
>> PREFIX dcterms:  
>> PREFIX defn:  
>> 
>> PREFIX deo:  
>> PREFIX doco_sop_shapes:  
>> 
>> PREFIX edg:  
>> 
>> PREFIX graphql:  
>> 
>> PREFIX imported:  
>> 
>> PREFIX metadata:  
>> 
>> PREFIX orb:  
>> PREFIX owl2xml:  
>> 
>> PREFIX owl:  
>> 
>> PREFIX pattern:  
>> 
>> PREFIX rdf:  
>> 
>> PRE

Re: [topbraid-users] Content tag set - tag display fails

[Richard Cyganiak]

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



> On 19 May 2021, at 05:50, robatki...@gmail.com  
> wrote:
> 
> 
> 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..
> 
> On Wednesday, 19 May 2021 at 12:44:06 UTC+10 Holger Knublauch wrote:
> 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
> 
> 
> 
> On 2021-05-18 11:00 pm, robatki...@gmail.com 
>  wrote:
>> 
>> If I use the UI to create a tagset, when I display a tagged property the 
>> error log shows a warning:
>> 
>> URI  
>>  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 arg:  
>> PREFIX dash:  
>> PREFIX dc:  
>> 
>> PREFIX dcterms:  
>> PREFIX defn:  
>> 
>> PREFIX deo:  
>> PREFIX doco_sop_shapes:  
>> 
>> PREFIX edg:  
>> 
>> PREFIX graphql:  
>> 
>> PREFIX imported:  
>> 
>> PREFIX metadata:  
>> 
>> PREFIX orb:  
>> PREFIX owl2xml:  
>> 
>> PREFIX owl:  
>> PREFIX pattern:  
>> 
>> PREFIX rdf:  
>> 
>> PREFIX rdfs:  
>> 
>> PREFIX sh:  
>> PREFIX skos:  
>> 
>> PREFIX skosshapes:  
>> 
>> PREFIX skosxl:  
>> 
>> PREFIX smf:  
>> 
>> PREFIX sp:  
>> PREFIX spar:  
>> PREFIX spin:  
>> PREFIX spl:  
>> PREFIX sro:  
>> 
>> PREFIX swa:  

Re: [topbraid-users] Content tag set - tag display fails

[robatki...@gmail.com]

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..

On Wednesday, 19 May 2021 at 12:44:06 UTC+10 Holger Knublauch wrote:

> 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
>
>
> On 2021-05-18 11:00 pm, robatki...@gmail.com wrote:
>
>
> If I use the UI to create a tagset, when I display a tagged property the 
> error log shows a warning:
>
> URI  
>  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 arg:  
> PREFIX dash:  
> PREFIX dc:  
> 
> PREFIX dcterms:  
> PREFIX defn:  
> 
> PREFIX deo:  
> PREFIX doco_sop_shapes:  
> 
> PREFIX edg:  
> 
> PREFIX graphql:  
> 
> PREFIX imported:  
> 
> PREFIX metadata:  
> 
> PREFIX orb:  
> PREFIX owl2xml:  
> 
> PREFIX owl:  
> 
> PREFIX pattern:  
> 
> PREFIX rdf:  
> 
> PREFIX rdfs:  
> 
> PREFIX sh:  
> PREFIX skos:  
> 
> PREFIX skosshapes:  
> 
> PREFIX skosxl:  
> 
> PREFIX smf:  
> 
> PREFIX sp:  
> PREFIX spar:  
> PREFIX spin:  
> PREFIX spl:  
> PREFIX sro:  
> 
> PREFIX swa:  
> PREFIX swrl:  
> 
> PREFIX swrlb:  
> 
> PREFIX tagger:  
> 
> PREFIX taggershapes:  
> 
> PREFIX teamwork:  
> 
> PREFIX teamworkconstraints:  
> 
> PREFIX tosh:  
> PREFIX ui:  
> PREFIX xml:  
> 
> PREFIX xsd:  
> 
>
> SELECT ?predicate ?predic

Re: [topbraid-users] Content tag set - tag display fails

[Holger Knublauch]

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


On 2021-05-18 11:00 pm, robatki...@gmail.com wrote:


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


URI  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 arg: 
PREFIX dash: 
PREFIX dc: 
PREFIX dcterms: 
PREFIX defn: 
PREFIX deo: 
PREFIX doco_sop_shapes: 
PREFIX edg: 
PREFIX graphql: 
PREFIX imported: 
PREFIX metadata: 
PREFIX orb: 
PREFIX owl2xml: 
PREFIX owl: 
PREFIX pattern: 
PREFIX rdf: 
PREFIX rdfs: 
PREFIX sh: 
PREFIX skos: 
PREFIX skosshapes: 
PREFIX skosxl: 
PREFIX smf: 
PREFIX sp: 
PREFIX spar: 
PREFIX spin: 
PREFIX spl: 
PREFIX sro: 
PREFIX swa: 
PREFIX swrl: 
PREFIX swrlb: 
PREFIX tagger: 
PREFIX taggershapes: 
PREFIX teamwork: 
PREFIX teamworkconstraints: 
PREFIX tosh: 
PREFIX ui: 
PREFIX xml: 
PREFIX xsd: 

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?



--
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-users+unsubscr...@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 
.


--
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/dfa74e8d-cf26-5c6f-76e1-37072b228365%40topquadrant.com.

[topbraid-users] Content tag set - tag display fails

[robatki...@gmail.com]

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

URI  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 arg: 
PREFIX dash: 
PREFIX dc: 
PREFIX dcterms: 
PREFIX defn: 
PREFIX deo: 
PREFIX doco_sop_shapes: 
PREFIX edg: 
PREFIX graphql: 
PREFIX imported: 
PREFIX metadata: 
PREFIX orb: 
PREFIX owl2xml: 
PREFIX owl: 
PREFIX pattern: 
PREFIX rdf: 
PREFIX rdfs: 
PREFIX sh: 
PREFIX skos: 
PREFIX skosshapes: 
PREFIX skosxl: 
PREFIX smf: 
PREFIX sp: 
PREFIX spar: 
PREFIX spin: 
PREFIX spl: 
PREFIX sro: 
PREFIX swa: 
PREFIX swrl: 
PREFIX swrlb: 
PREFIX tagger: 
PREFIX taggershapes: 
PREFIX teamwork: 
PREFIX teamworkconstraints: 
PREFIX tosh: 
PREFIX ui: 
PREFIX xml: 
PREFIX xsd: 

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?



-- 
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-users+unsubscr...@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.