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.
--
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.
