Hi Parsa, thanks for raising this topic. We have already made several improvements to optimize TBC for SKOS editing for version 3.3. One of them is that skos:prefLabel will be preferred over other labels.
I have also just committed a change that will modify the way human-readable
labels will be displayed. If two resources have the same rdfs:label, then their
qname will be printed behind the label, distinguished between [...]. For
example, both owl:Class and rdfs:Class have the label "Class". The current
approach will render them as
Class [owl:Class]
Class [rdfs:Class]
We will be experimenting with this approach for a while, and (hopefully) leave
it in for the next version. Please let me know if you anticipate problems with
that.
Regards
Holger
On Jan 14, 2010, at 4:51 PM, Parsa Mirhaji wrote:
> 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.
-- 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.
