Thanks Holger and Irene for the info and the comments! Kind regards,
Wim Op woensdag 7 januari 2015 00:13:27 UTC+1 schreef Holger Knublauch: > > On 1/6/2015 19:39, Wim wrote: > > Hi, > > I'm enjoying TBC 4.6 a lot (I really like the features and the UI), as > well as the SPIN java API which is a great companion for automating some > tasks. But there are a couple of (minor) things I've noticed which, at > least from my perspective, would be useful to fix/enhance: > > > Thanks for your feedback! > > > > - When I specify rules in TBC that contain nodes of the default > namespace (i.e. :myNode instead of myNS:myNode) then SPIN API complains > about these rules. Don't know if this is a problem of TBC (should sp:text > only contain fully qualified nodes?) or of SPIN API. > > > What error message are you getting when you use the default namespace? In > general, I would advise anyone against using default namespaces, because > they can easily lead to confusion depending on the order of subgraphs in a > union graph. It is also often confusing to the algorithms to pick the right > choice when a namespace is abbreviated both with "" and another prefix. > > > - It would be nice if more "useable" information is sent to the SPIN > API ProgressMonitor, such as the iteration number as an integer and rule > name as a string. Now the only way to extract this information, seems to > parse the so-called subtask label. > > > Good idea, now recorded on our bug tracker. > > > - Inferencing with SPIN API is a lot faster than inferencing with TBC > (factor 8 or so). Perhaps the constant updating of the TBC progress widget > is the culprit? If this is the case, maybe it makes sense to provide the > possibility to turn off these widget updates? Or better yet, perhaps a > more > advanced progress widget would allow the possibility to show only "high > level" information such as the current iteration number, and would show > additional information such as a progress bar, busy time, etc.? > > > Weird, we will investigate. > > > - In TBC, suppose you create a new ontology that imports other > ontologies, and you create subclasses of existing (imported) classes. In > this case, it would be nice to visualize in the Classes View which "paths" > contain subclasses of the currently active ontology, and which don't. Just > like individuals can be found very easily due to the "(<number>)" suffix, > it would be nice to see which classes lead to subclasses of the currently > active ontology, and which don't. Perhaps the imported classes that don't > contain subclasses of the currently active ontology could have a gray font > instead of a black one? > > > In addition to the suggestion by Irene you may also find "Model > Find all > locally defined resources" useful. > > > - Not sure if it's a legitimate remark or not, but I for one wouldn't > be unhappy to see SPIN API appearing on GitHub... > > > Absolutely. I have recently started work on a next generation of SPIN as a > candidate proposal for the ongoing Shapes W3C group, and plan to publish > that version as a public github project once the group signals interest in > this work. The complication is that we also need a copy of this for the > TopBraid code base, and branching etc would become very complicating if > this were spanning multiple github projects. My approach would be to make > the edits on the TopBraid code base first, and periodically copy over the > changed files to the public repository. This will hopefully also allow us > to more easily receive external contributions. > > But for now I need to ask for patience until the W3C direction has been > clarified. > > Thanks again, > Holger > > -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, 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.
