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

Re: [topbraid-users] TBCME 6.4 crashes in SPINMap Diagram

[Holger Knublauch]

On 2021-05-20 7:30 am, Jack Hodges wrote:
I have been having stability issues with TBCME 6.4 where it crashes 
several times a day, but I began a SPINMap project yesterday and it is 
hanging every 15-30 seconds, requiring me blast the process. I would 
use TBCME 7.0 but I have been having issues with even starting that 
one so I am reluctant to move operations over to it. Is this stability 
problem fixed in 7.0?


I doubt it, because nothing related to SPINMap has been touched for a 
while, and TBC 7.0 is not much different from 6.4 feature-wise. It would 
help us better understand the crashes if you could send the Eclipse 
error log with Exception stack traces. I don't know what to do with the 
other file you have sent.


Holger


It would be worth the switch if I can do something that should take 
minutes in less than a day. Sorry to be whiner.


Jack

Macbook Pro 2018
2.6 GHz 6-core Intel Core i7
32 GB 2400 MHz DDR4 memory
macOS Big Sur, version 11.3.1
--
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/c49d356e-e5b2-4313-b9e2-0fb33d65976dn%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/ed2668c3-136b-ef8e-cf49-3bece7c5cc59%40topquadrant.com.

Re: [topbraid-users] XML fromn RDF wizard in TBCME (tutorial anywhere?)

[Jack Hodges]

I'll take a look, thanks. In the meantime I went to another approach 
(convoluted but it worked), where I took a sample XML, backed out an XSD, 
imported the XSD into TBC, created the OWL file, and proceeded on to the 
real task of building a SPINMap to my ontology (another problem reported 
elsewhere). But I will look over this solution as it would have been the 
preferred approach. Thanks.

Jack

On Tuesday, May 18, 2021 at 3:49:48 PM UTC-7 Holger Knublauch wrote:

> Hi Jack,
>
> there are many ways of mapping RDF to XML. What output would you like to 
> produce? Do you mean RDF/XML, XML based on our Semantic XML technology or 
> some arbitrary XML?
>
> One new technique to produce arbitrary XML is Active Data Shapes (ADS), 
> see the last example in
>
> http://datashapes.org/active/tutorial.html#getting-started
>
> which produces HTML yet the same approach works for XML.
>
> Holger
>
>
> On 2021-05-19 3:04 am, Jack Hodges wrote:
>
> I have created an OWL/RDFS model and populated it with some data 
> (manually). I want to export this data to XML so that I can test an ingest 
> SPARQL MOTION script. There is a TBCME export wizard called XML from RDF 
> which asks for an output file and an instance, and it tries to work but 
> produces empty files. Clearly I am not using it properly. Is there one of 
> Holger's videos that shows how to make this work, or a tutorial? I've been 
> wandering the site and the forum looking and I don't really want to write a 
> SPARQL MOTION script to do it if there is already an export utility that 
> does it. Thanks for pointers. 
>
> Jack
>
> -- 
> 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/9a2b523e-a8f3-4eb5-ac81-91404b1997c3n%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/6d7e9fb9-d7fd-4d72-87b7-1a18fb2c1b6fn%40googlegroups.com.

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: