Yes, I think this is the reason why I am not seeing what I was expecting from TBC in my model. Here are my 2 cent about how I would have liked it to work:
Context: my comments here are NOT from the position of someone that creates his stand alone vocabularies for this system or that use case. I am looking at it from the perspective of metathesauri or mash-ups that may be comprised of resources pulled in from several skos:ConceptSchemas. Secondly there are issues of extensibility and merging of an stand-alone vocabulary with other non-skos resources that will come in play in realistic application environments. After all, skos defines itself in the realm of OWL-FULL models that to me it means an invitation to creative combination of nonsensical modeling practices by people that will immediately enlist many reasons to believe that if they do otherwise the skies will fall (and that includes yours truly). Taking a few steps backward, and looking at it from a greater distance it looks to me similar to those things that Tim Berners Lee called Semantic Web: Letting people say many things in many places, but have a way for 'consistently' putting them together when needed and as needed. So, there are also philosophical/theoretical aspects to the question of how we work with labels that goes beyond what we may come up with in this discussion. First, skos itself introduces a concept of 'integrity conditions' in its latest release that is explicit about use of labels in an skos model. According to the skos documentation at http://www.w3.org/TR/skos-reference/ :"Integrity conditions serve primarily to establish whether given data are consistent with the SKOS data model . All other statements within the definition of the SKOS data model serve only to support logical inferences." What this means to me, is that integrity of an skos model is different from inconsistency of the model in regards to rdfs/owl logic. Secondly, the skos integrity condition for use of labels depend on two other constrains other than equality of the strings: language tags used (if any), and the skos:ConceptScheme governing the model. That is, it is not enough to say that there are two strings that are equal, in order to tag for inconsistency. It is allowable to have two resources in the same model, to have the same labels but from different skos:ConcetpScheme. This may be more complicated if one considers the fact that a resource may be in more than one skos:ConceptSchema. This is critical to enable creation of mash-ups and metathesauri out of several skos models. My personal experience is that although skos integrity checking scheme makes a lot more sense than simply checking for uniqueness of the strings used as labels and can account for majority of the mashing up and thesauri cases, it is not realistic and can be ignored as long as we are not breaking the RDFS/OWL consistency by doing it. There are complexities that may arise when we extend an skos model (by sub propertiesOf or subClassOf relations), or merge it with other exiting models outside of our own system (import a non skos model), in these more realistic environments concepts and properties may share the same label (this was why my SN:Clinical_Drug didn't work because there was a rdf:property in the model with the same label!). That is, although the model conforms with the skos semantics, the tool enforces a different strategy. In real world there might be other things that have similar labels but different semantics and uri from different namespaces, as there might be resources with the same label and same semantics but different uri (that is why we need owl:sameAs). Probably most problematic scenarios arise from extending skos models by way of adding rdfs:subPropertyOf the a skos:prefLable and using them in different contexts, and then applying a reasoning on top of your model that will inevitably create 'integrity problems' that are all made with good intentions in mind. It is my understanding that skos as is, is a domain and context independent model. That to me means that extending it to cope with particularities of specific tasks, and domains is inevitable and expected. So as a practice I always find myself extending not only the skos labels, but also all other semantic relations and notes and so forth. I don't have a model that does not do this, ie., I can't use TBC's Human readable labels for none of them. More importantly, in UMLS, which is one the largest if not the largest, metathesaurus in biomedicine, the commitment to a single preferred label does not exist. As a matter of fact there exist several different kinds of preferred labels: Preferred Term, Human readable preferred term, source designated preferred term, Chemical preferred term... What do we do then? A more delicate problem that may not be as obvious but with great implications arises when one decides to use the skos-xl namespace to work with the skos extended labels. In my case (and that is why none of my instances are showing their labels) all skos concepts have their own skos:prefLable and also they have their extended label object with several other annotations and relations, and of course a label that is the same as the skos:prefLable. Long story short, with current TBC strategy using skos-xl namespace would not work with the human readable labels function, although the model conforms completely to skos framework. All these scenarios necessitates that one would be able to attach the labels as appropriate to their use case and hope that the notion of integrity checking for skos model, and interoperability of skos models, and consistency checking of the underlying rdfs/owl model are not dependent to each other functionally, or problems can be isolated and dealt with without loosing granularity, context or resulting in misrepresentation of information. From the skos references document it was implied that DL reasoning on skos models does not depend on the result of the integrity condition checking, although it can be used to enable it, ie., it is not necessary to be enforced by the modelers. Most of my problems using TBC for editing and using skos models roots in the fact that it blindly ignores labels if it finds anything else that resembles to it, even if it is not a skos:Concpet (an instance of skos:Concept with skos:prefLable='Red' and a non skos resource with rdfs:label='Red' will be suppressed). For skos concepts even it they belong to different schema (red hot chili peppers from music model and that from vegetables are supressed by TBC as being similar resources) they will also be suppressed. So from the perspective of a modeler I would expect that the tools I use respect that I may have reasons for doing what I am doing and enable me to 'consistently' use them in different situations without a lot of learning curve and situation specific know-how. >From that perspective, I would expect that the integrity checking would be >implemented as : 1- a selectable option and not as a system behavior: that is, ask if I want you to detect and report if other resources found with the same label. 2- in minimum check for the governing ConceptScheme and only enforce an apple to apple match, that is if schema and the properties used are the same (not perfLable of one resource being similar to the rdfs:lable of another resource) 3- make it available as a reporting tool rather than enforcing tool: tell us that there exist problems (similar to the way consistency checking works) rather than changing the behavior of the system That is, I would expect options to pick from (use labels or skos:prefLables or interchably as it is implemented now, or turn the skos integrity checking off, show qname or an skos:altLabel or ... in case of conflict between resources...) Thanks Parsa On 1/14/10 1:42 PM, "Dean Allemang" <[email protected]> wrote: I'm not sure if this is what is going on here, but something I have found when using TBC as a SKOS editor that can be counter-intuitive is that TBC won't show a prefLabel if it is not unique. That is, if there are two resources with the same prefLabel, it will punt back to the qname (or something like that), rather than the (non-unique) prefLabel. I myself haven't figured out what I think about this policy; on the one hand, it avoids confusion for vocabularies in progress, but on the other hand, it can lead to strange non-local behavior. I have used this on more than one occasion as a quality control mechanism for vocabularies, but that only makes sense if your vocabulary management policy disallows duplicate prefLabels (many do not; in fact, a more common policy is only to disallow duplicate prefLabels as siblings in the skos:broader tree). So, first, see if this is the case in your model, and is responsible for the anomalous behavior. Second, I would be interested to have your perspective on what the 'correct' behavior is, in face of duplicate prefLabels. And duplicate rdfs:labels. And whether you are in the habit of making subPropertiesOf skos:prefLabel, and what you think appropriate behavior in that situation would be. Dean Parsa Mirhaji wrote: > Scott > Thanks for the heads up about the reverse direction of the tree, that > helped. However, now that you pointed out about the use of the human > readable lables (skos:prefLable) it seems not working consistently? > From the screenshot below you can see that the instances of classes > are not shown through their human readable labels (neither in the > instances view nor in the Associations view. However instances of an > owl:Class are consstently shown by their skos:prefLable. > Secondly if you look at the SN:Clinical_Drug class (highlighted and > selected in the right side panel), although it does have a > skos:prefLabel and a matching label for that matter, it does not show > up neither in the class view nor in the instances view... I looked > into the file but didn't see a difference on what may be causing this? > As the model is constructed running a script, it should be created the > same way as others... > So the most important question from my perspective is how to get the > lables work with the instances because that is what will make the > difference in usability of the TBC as an SKOS editor... > Thanks > Parsa > > > > > > On 1/14/10 11:00 AM, "Scott Henninger" <[email protected]> wrote: > > Hello Parsa; Some thoughts below. If these don't help out you may > want to send an example we can look at. > > <a hierarchy is expected to be built through following a provided a > selected property (or so is my understanding)> > > Yes, this is the case, but keep in mind that the default layout for > this view is like rdfs:subClassOf. I.e. higher levels of the tree are > objects of the lower level's subjects. I.e. in your case: > :C0000970 :rb :C0724005 > > You can use Switch direction (top-right of view) to reverse this. > > From what I see in the image, if there were a relationship somewhere > of the form: > :xyz :rb :C0000970 > > ...then it will appear as a next level of the tree beneath :C0000970. > Note that the properties shown in :C0000970's form are in the opposite > direction: > :C0000970 :rb :C0074808 > > (BTW, if you turn on human readable labels - see person icon in top > icon menu - you would see the skos:prefLabel in the tree. I.e. it > would read "Acetaminophen" instead of "C0000970".) > > -- Scott > > On Jan 13, 3:57 pm, Parsa Mirhaji <[email protected]> wrote: > > When using the Associations View in TBC-ME 3.1.1 a hierarchy is > expected to be built through following a provided a selected > property (or so is my understanding). However, when I use a > property (:rb in this case as illustrated in the image below), it > only goes one step forward, although there are other objects > associated with that same property to the selected node (as seen > in the right hand side panel from the image below). Any insight? > > > > [cid:3346243025_8346651] > > Thanks > > Parsa > > > > Parsa Mirhaji, MD. PhD. > > Assistant Professor > > The School of Health Information Sciences > > The University of Texas Health Science Center at Houston > > Tel: (713) 500-3157 > > Fax: (713) 500-0370 > > Assistance (Connie Tapper): (713) 500-3937 > > > > Please consider environment before printing this email or its > attachments. > > > > image.png > > 49KViewDownload > > > Parsa Mirhaji, MD. PhD. > Assistant Professor > The School of Health Information Sciences > The University of Texas Health Science Center at Houston > Tel: (713) 500-3157 > Fax: (713) 500-0370 > Assistance (Connie Tapper): (713) 500-3937 > > *Please consider environment before printing this email or its > attachments.* > > ------------------------------------------------------------------------ > > -- > You received this message because you are subscribed to the Google > Groups "TopBraid Composer Users" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/topbraid-composer-users?hl=en. Parsa Mirhaji, MD. PhD. Assistant Professor The School of Health Information Sciences The University of Texas Health Science Center at Houston Tel: (713) 500-3157 Fax: (713) 500-0370 Assistance (Connie Tapper): (713) 500-3937 Please consider environment before printing this email or its attachments.--
You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/topbraid-composer-users?hl=en.
