The problem probably isn't in the closed world of Composer but in the more complicated world of interacting with different data sources. I have seen scenarios where Composer is having profound difficulty with unicode characters, requiring the kind of transformations that Courtland describes. These aren't fantasies. For example, what if you want to import the content of a file from the web into labels, comments, or descriptions (or other properties) in Composer. The content might very well be encoded as UTF-8 or Unicode. Were it written in Composer it might be handled fine, but when imported it might not. Same for export. What if you want to write an SWP that constructs XML/HTML or even Latex. What you see in Composer might be fine but the content produced might not. We live in a world that requires interaction and integration with different data sources, and for Composer to be truly useful (to truly shine) it must be able to accommodate these interactions and integrations seamlessly. That is more or less how I interpret Courtland's comment/lament.
Jack On Thursday, November 1, 2012 3:08:57 PM UTC-7, Bob DuCharme wrote: > > Hi Courtland, > > TopBraid Composer has full Unicode support. I just used a text editor to > create a Unicode UTF-8 Turtle file that included both the name Schrödinger > and some Kanji characters and TopBraid Composer opened the file and > displayed the non-ASCII characters just fine. > > Do you know what encoding your file was in? > > Bob > > > On Thu, Nov 1, 2012 at 5:35 PM, ceyockey > <courtlan...@astrazeneca.com<javascript:> > > wrote: > >> There are two discussion threads already present here which include >> mention of Composer's not handling character encoding well; these are from >> 2011. What I am trying to do is simply conduct an "Import Triples from >> this File into current Model" from a Turtle file (.ttl) into an RDF file >> (.rdf). I've had problems with doing this due to some bizarre characters >> in the inputs, which I am manually removing or transforming. However, I >> came across a skos:prefLabel with the value "Schrödinger software" which >> results in a "Could not inspect file..." error. >> >> The workaround for this which I will need to use is encoding the "ö" as >> the HTML/XML equivalent "ö". This will at least preserve the >> content in a form which can be reconstructed, but this is far from ideal. >> One could presumably use the Unicode equivalent of "U+00F6", but this would >> present problems due to it's not being a delimited token as the HTML/XML >> value is. >> >> I am wondering when you might be able to release a Composer client which >> includes support for extended Latin character sets which contain the most >> commonly used non-ASCII characters such as this one? >> >> Thanks --Courtland Yockey >> >> -- >> -- You received this message because you are subscribed to the Google >> Group "TopBraid Suite Users", the topics of which include Enterprise >> Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, >> TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN. >> To post to this group, send email to >> topbrai...@googlegroups.com <javascript:> >> To unsubscribe from this group, send email to >> topbraid-user...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/topbraid-users?hl=en >> >> >> > > -- -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to topbraid-users@googlegroups.com To unsubscribe from this group, send email to topbraid-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en
