Menu
▾
▴
Re: [Semediawiki-user] Mapping of traditional database to wiki
|
From: Rolf L. <rol...@ri...> - 2009-01-16 01:09:09
|
Solbrig, Harold R. skrev: > Rolf, > > Just responding to you because I'm not positive that the issues you are > addressing are what we are addressing. Your example falls within the problem at hand, yes. As for the specific lingual problem, see the other post for a solution (works on systems with complied code using MultiLingualStrings (MLStrings) for both system messages and data). BTW, interesting that you mention a biological example. We're onto designing a site for amino acid analysis (upload or post (manually) your amino acid string sequence. We plan to use SMW as a middle ware for that. It would also be interesting to design a "gene model execution" tool for executing Genetic Regulatory Network (GRN)s. Why specify GRNs in tools like BioTapestry if not also executing the models...? http://sugp.caltech.edu/endomes/BrowserOnly/emvfgSmallImage.html UML seems not to support notation for promoters and repressors of genes, however. :) Regards, // Rolf Lampa [RIL] Solbrig, Harold R. skrev: > Rolf, > > Just responding to you because I'm not positive that the issues you are > addressing are what we are addressing. (Besides, I just hate responding > on mailers...) > > We have a situation where we are managing terminologies. One of the > principles of a "well formed" terminology is the use of a "non-semantic" > identifier, that is language and hierarchy neutral. As an example, > "Gene" (http://biomedgt.nci.nih.gov/index.php/Category:BGT_Gene(B16785) > ) in the BiomedGT thesaurus has an id of "B16785". > > What we ended up doing is constructing a 3-part identifier. The first > part is the "namespace id" (Talking XML/RDF here, not mediawiki), which > serves to render the rest of the identifier unique. This is because it > is possible, say, for both BiomedGT and some other terminology to use > the "B16785" identifier. The second part is the language specific, > preferred name. In English, it might be "Gene", but it could be > something different in another language. In addition, it is possible > that this preferred name might change over time. The third part > "(B16785)" is the unchanging id. > > The three parts give us a combination of human readable and language > independent pages. We have a set of parsing utilities that cut 'n > splice these things as needed and, while we have yet to implement this > bit, our intention was to intercept a missing page and, if it was of the > form above, we would look up the page using "BGT" and "B16785" and > create a redirect message to the effect of the locaion of > "BGT_Gene(B16785)" has changed. Please change link to > "BGT_YYYY(B16785)"... > > Would be glad to provide code or more detail if this would be of use > > > Harold Solbrig | Division of Biomedical Statistics and Informatics | > 507-293-3774 | sol...@ma... > > -----Original Message----- > From: sem...@li... > [mailto:sem...@li...] On Behalf Of > Rolf Lampa > Sent: Thursday, January 15, 2009 4:17 PM > To: jo...@na... > Cc: sem...@li... > Subject: Re: [Semediawiki-user] Mapping of traditional database to wiki > > Yaron Koren skrev: > >> Well, at the very least, I've never seen an interface that has a >> dropdown for selecting an address. >> > > > Well, I have. > > Think of a (more interactive) form (not web form though) where you first > > type in a PostalCode, then a list of available/possible (street) > addresses would be narrowed down significantly. I designed an enterprise > > system for a transport company, and believe me, address objects where of > > the greatest interest. An ordinary transport booking could involve up to > > 6 (six) different addresses, so you can imagine that the people entering > > bookings had very high demands on the "helpfulness" of the UIs - no > time for looking things up, no time or room for errors, none, only > correct on first try would do. > > > >> Is there another example you could offer? >> > > > It's not difficult to imagine that natural id:s based on natural "names" > > of things wouldn't work for example in a multi lingual system / context, > > where the items, like product names for example, could differ depending > on user language. > > I built a multilingual enterprise system which had three major language > "contexts", #1. User Interface (User's language), #2. data on printed > Forms and Invoices, and system-internal data as fall-back default/root > language if a requested multilingual string was missing. > > AYAE (as yet another example) you can also try to imagine what happens > to a data structure holding Activities assigned to FunctionalRole(s) or > Titles, designed for use in a multi lingual company (my wife works on a > company which have 16 different nationalities, like Iraq, Sudan, Taiwan, > > Finland, Vietnam, Sweden, Lebanon, Saudi Arabia, Sri Lanka, India, Chile > > ... aso. > > They are all hired to fulfill critical named Roles in the company, with > critical safety instructions to follow (food industry, see HACCP for > example) which MUST be well understood by all, all this preferrably > communicated in peoples own tongue. But then you can imagine that the > "natural id:s" of Activity objects, Titles, functional Roles etc simply > won't work in User Interfaces. > > Instead individual objects *must* be identified (by the users) > indirectly, via MultiLingual strings, that is, the UI displays one > thing, but the technical system deals with another (like unnatural id:s > etc). A fixed descriptive title in one language wouldn't make sense as > an Id key for a Reference to an objcet with a descriptive name. > > In other woirds, "natural" Id:s just doesn't work in all cases. > > And since I'm designing a generic SmwModeler tool I need to be able to > handle all cases. All cases means no execption. I aim to autogenerate > Forms for navigating ANY data structure, and that requires being able to > > generate "AutoForms" automatically from a given data model. > > == Almost there! == > > Hey, you're almost there already with SMW Forms. I mean, SMW Forms is > already capable of almost anything you need, all it takes is adding to > it to be able to retrieve & display one thing, while being able to > *assign* another thing on submit, and there you go. :) > > As I see it, this (currently missing) feature in the SMW Forms extension > > is the only thing stopping me from finalizing an entirely generic > SmwModeler tool capable of generating *any* data model. > > Regards, > > // Rolf Lampa > > > > Yaron Koren skrev: > >> Well, at the very least, I've never seen an interface that has a >> dropdown for selecting an address. Is there another example you could >> offer? >> >> -Yaron >> >> On Thu, Jan 15, 2009 at 4:11 PM, Rolf Lampa <rol...@ri... >> <mailto:rol...@ri...>> wrote: >> >> >> It was only an example to illustrate the technical problem >> (assignment of PageReference and PageLists). >> >> However, you'd find Address classes in many modern enterprise >> systems. Data should be spatial in these days, as you know, and an >> Address object can hold generic "location" info like geo >> coordinates, reference to City class, PostalCode/Area, residents, >> inhabitants, etc. >> >> Legacy data will always force you to deal with the typical problem >> I exemplified. >> >> Regards, >> >> // Rolf Lampa >> >> >> >> Yaron Koren skrev: >> >> Wow, okay... I don't think I've ever heard such a proposal >> before, but I could be wrong. >> >> Something that jumps out at me from the example is that a home >> address is treated as an "object", with its own ID in the >> original database, its own page in the wiki, and its value >> selectable from a dropdown list. This seems very odd to me, >> since there's usually nothing significant to an address other >> than the fact that someone lives there, and the chance that >> two random people share an address is quite low. I've only >> ever seen addresses represented as a simple text entry, in >> wikis and otherwise. Can you explain this? >> >> -Yaron >> >> >> On Thu, Jan 15, 2009 at 3:20 PM, Rolf Lampa >> <rol...@ri... <mailto:rol...@ri...> >> <mailto:rol...@ri... <mailto:rol...@ri...>>> >> wrote: >> >> Yaron Koren wrote: >> >> >> If I (or you) could only convince Yaron Koren to >> > enhance > >> his SMW Forms >> to support drop lists displaying SMW queried article >> titles >> OR field >> WHILE assigning another (optionally hidden) co-field >> (based >> on a >> two-column list generated with a smw query), as such >> > a > >> feature would >> allow generating "SMW Auto Forms" for legacy >> > database > >> models browsing >> (and modifying?...) legacy data without any manual >> tweaks >> whatsoever. >> >> >> I don't understand what you want to convince me to do. >> > :) > >> Could you give an example of what you're talking about? >> >> >> Yes, I'm eager to. :) >> >> Short version: Form should be able to >> >> 1. retrive two (or n*) columns >> 2. using a direct #ask: or concept(#ask: -query, or via >> template, >> 2. although displaying only n-1 columns to the user. >> 3. finally, on form submit the form would assign one >> > specified > >> column (hidden or not) to the form field at hand. >> >> Longer version: >> >> Example - When assigning a relation from a Person to a home >> address (Address) I'd want to select, well, an Address. >> Given that >> I have a legacy data with zillion instances of Address, I'd >> configure the SMW Form Form:Person to show a listbox with >> Address >> info, with the listbox holding two columns* of data (while >> hiding* >> one): >> >> {{{field >> | UniqueID >> | mandatory >> | listbox >> |columns=2 >> |values={{AddressListForSMWFormAddress}} >> |assign-column=1 >> |hide-column=1 >> }}} >> >> The query in the template AddressListForSMWFormAddress >> could look >> something like this: >> >> {{#ask: [[Category:Address]] >> | ?UniqueID= <-- "assign-column=1" >> | ?Street= >> | ?PostalCode= <-- but display n columns* >> | mainlabel=- >> }} >> >> kinda. The point is be that the first column of the list >> (UniqueID) would be hidden from the user, not shown either >> in the >> listbox nor on the form, although serving as a reference, >> > or > >> "singlelink" to another page. >> >> So when the user sees the list items, he sees only Street >> names (+ >> whatever other columns), and he selects the desired >> Street/OtherColumn row, and presses the Submit button, and >> the SMW >> Form will then assign the address' (hidden) UniqueID to the >> (hidden) field on the form. >> >> In this way one could generate "AutoForms" and the user >> could then >> both browse and modify legacy data "as is", even knowing >> what one >> is doing, since relations can be traversed AND assigned >> > without > >> displaying disturbing unnatural id:s to the user (silly >> > numbers > >> and/or GUIDs or whatever cryptic ids legacy relational data >> can be >> hidden at all times). >> >> A UML diagram for the relation: >> >> [ Person ]--------homeAddress-1->[ Address ] >> [ ] [ uniqueID ] >> >> ...where the property "homeAddress" is assigned (in the >> Template:Person) like so: >> >> {{#set:HomeAddress={{#ask: [[Category:Address]] [[ >> uniqueID::{{{HomeAddressRefId|}}}]] }} >> }} >> >> >> Regards, >> >> // Rolf Lampa >> >> * columns: It'd be good to be able to show 1+2 columns >> since an ID >> might not be useful to show to the user, and a single >> column might >> not help the user to distinguish a desired unique listitem. >> An alternative approach would be to derive the one extra >> > column > >> which is displayed via a template, where one can built up a >> string >> of data from multiple fields (This is not always optimal >> "readability" though, because concatenated strings doesn't >> align >> like columns does). >> >> >> >> > > ------------------------------------------------------------------------ > ------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > |