Yes to your license question Sent from my iPhone
> On Apr 21, 2017, at 8:40 AM, sanjeev devireddy <[email protected]> > wrote: > > Yes, I do agree that there is a difference between 1) Demonstrating that > services I have developed locally work on the server & 2) Demonstrating that > I can access data on the server from local TBC. > > For now, since there is a risk in deploying the project to our server (which > is the only one EVN instance/environment available for our team and our > stakeholders load vocabularies in that server) so our goal is to demonstrate > that we can access data from the server through the services > developed/deployed in local TBC. > If this doesn't work then as you suggested we may need to wait till our sever > is upgraded to 5.2. > > Coming to our actual goal, it is to generate a HTML report/page for a given > vocabulary and it is explained with screen shots in the discussion > https://groups.google.com/forum/#!topic/topbraid-users/DlY44RFw6K4. > > Regarding the option of downloading the version of TBC that corresponds to > our server, I just have a quick question and that is, does the license that I > use for the TBC 5.2.0 work with any(number of) TBC version(s) in my local? > > > Thanks, > sanjeev > > > >> On Friday, April 21, 2017 at 3:50:56 PM UTC+5:30, Irene Polikoff wrote: >> It would seem to me that demonstrating that services you have developed >> locally work on the server would be different from demonstrating that you >> can access data on the server from local TBC. >> >> What is the goal of the PoC? >> >> In any case, I think you wrote an email saying that you were planning to >> upgrade the server to 5.2. Then, there should be no issue with your services. >> >> Another option may be for you to download the version of TBC that >> corresponds to the server, test the services with it, then deploy. >> >> Sent from my iPhone >> >>> On Apr 21, 2017, at 3:05 AM, sanjeev devireddy <[email protected]> >>> wrote: >>> >>> Actually as a proof of concept, we developed some REST services(as >>> mentioned in the first post) and those services work fine with the EVN's >>> default vocabulary Geography. Now we are asked to point those services(in >>> local composer) to our pilot EVN instance Vocabularies(which are loaded by >>> our stakeholders) so that those REST services fetch data from our >>> pilot/remote EVN instance Vocabularies. For that we are using the SERVICE >>> keyword in the SPARQLs of those REST services. Since those REST services(in >>> local composer) don't work with the SERVICE keyword to fetch data form our >>> pilot/remote EVN instance so we thought of going by two alternatives as >>> given below.. >>> >>> 1) Deploying the project in our pilot EVN instance. But our local >>> composer/EVN version(5.2.x) is greater than our pilot EVN instance(5.1.x) >>> so this may cause some issues. >>> 2) Loading the Vocabulary from our pilot EVN instance to local EVN. But >>> from past 3 days, my local EVN throws No Session Manager Exception. For >>> this I started another >>> discussion >>> (https://groups.google.com/forum/#!topic/topbraid-users/dEtwlaFXVLQ) in >>> this forum and waiting for help from others. >>> >>> >>> Thanks, >>> sanjeev >>> >>> >>> >>> >>>> On Friday, April 21, 2017 at 4:20:31 AM UTC+5:30, Irene Polikoff wrote: >>>> Yes, typically, {?var ?p ?o} is the same and much more efficient than {?s >>>> ?p ?o. FILTER (?s = ?var)}. >>>> >>>> In the context of the SERVICE keyword and, more generally, if ?var is >>>> unbound, results can be different. Queries are evaluated inside out and in >>>> the first case you may get everything since ?var is unbound, in the second >>>> case, nothing since ?var is unbound. >>>> >>>> In any case, I am not sure why you need a SERVICE keyword. It is typically >>>> used to federate queries across different endpoints. >>>> >>>> >>>>> On Apr 20, 2017, at 10:25 AM, sanjeev devireddy <[email protected]> >>>>> wrote: >>>>> >>>>> Hi Irene, >>>>> There is no specific reason to use ?s ?p ?o followed by a filter. >>>>> Actually I was trying different things since with SERVICE keyword that >>>>> service doesn't work. It was just one change among the different things >>>>> that I tried :) >>>>> >>>>> >>>>> Thanks, >>>>> sanjeev >>>>> >>>>> >>>>>> On Thursday, April 20, 2017 at 6:54:37 PM UTC+5:30, Irene Polikoff wrote: >>>>>> It is extremely not efficient to use the pattern: >>>>>> >>>>>> ?s ?p ?o followed by a filter, when ?s,?p and?o are all unbound. >>>>>> >>>>>> You are retrieving every single triple in the graph and then filtering >>>>>> out. It is also typically unnecessary. >>>>>> >>>>>> Is there any reason you can't replace it with simply: >>>>>> >>>>>> ?conceptURI ?p ?o. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Apr 14, 2017, at 9:09 AM, sanjeev devireddy <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> By following the examples given at http://uispin.org/swon.html, a >>>>>>> service is developed to get the properties(Predicates & Objects) of a >>>>>>> Concept as shown below. This code snippet works fine without the >>>>>>> SERVICE Keyword. But when the SERVICE keyword is used then the concept >>>>>>> URI value has to be hard coded otherwise zero results are returned. >>>>>>> >>>>>>> <swon:Array> >>>>>>> <ui:forEach ui:resultSet="{# >>>>>>> SELECT ?p ?o >>>>>>> WHERE { >>>>>>> SERVICE ?sparqlEndPoint { >>>>>>> GRAPH ?graphURI { >>>>>>> ?s ?p ?o . >>>>>>> FILTER (?s = ?conceptURI) . >>>>>>> } . >>>>>>> } . >>>>>>> } }" ui:separator=","> >>>>>>> <swon:Object> >>>>>>> <swon:Value arg:name="result" arg:value="{= ui:label(?p) >>>>>>> }"/> >>>>>>> <swon:Value arg:name="label" arg:value="{= ui:label(?o) }"/> >>>>>>> </swon:Object> >>>>>>> </ui:forEach> >>>>>>> </swon:Array> >>>>>>> >>>>>>> >>>>>>> URL to invoke the REST service >>>>>>> http://localhost:8083/tbl/swp?_viewClass=g:getProperties&graphURI=urn:x-evn-master:geo&conceptURI=http://topquadrant.com/ns/examples/geography%23Asia&sparqlEndPoint=<sparqlEndPoint_URI> >>>>>>> >>>>>>> I hope it is something to do with the way the URI is placed/passed >>>>>>> dynamically at the line FILTER (?s = ?conceptURI), when the SERVICE >>>>>>> keyword is used. Could some one please help us here? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> sanjeev >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Group "TopBraid Suite Users", the topics of which include the TopBraid >>>>>>> Suite family of products and its base technologies such as >>>>>>> SPARQLMotion, SPARQL Web Pages and SPIN. >>>>>>> To post to this group, send email to [email protected] >>>>>>> --- >>>>>>> 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 [email protected]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Group >>>>> "TopBraid Suite Users", the topics of which include the TopBraid Suite >>>>> family of products and its base technologies such as SPARQLMotion, SPARQL >>>>> Web Pages and SPIN. >>>>> To post to this group, send email to [email protected] >>>>> --- >>>>> 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 [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Group >>> "TopBraid Suite Users", the topics of which include the TopBraid Suite >>> family of products and its base technologies such as SPARQLMotion, SPARQL >>> Web Pages and SPIN. >>> To post to this group, send email to [email protected] >>> --- >>> 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 [email protected]. >>> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Group > "TopBraid Suite Users", the topics of which include the TopBraid Suite family > of products and its base technologies such as SPARQLMotion, SPARQL Web Pages > and SPIN. > To post to this group, send email to [email protected] > --- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include the TopBraid Suite family of products and its base technologies such as SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected] --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
