Re: arcs for locators with the same role

At 9:06 PM -0000 1/20/00, Matthew_Tolman@ovid.com wrote:
>I am working on an application for the storage and generation of XLinks.
>During the design of the application I realized that in an extended link
>you cannot create a link between two locators with the same role without
>making the link bi-directional.  Even though the problem is solvable by
>assigning 'unqiue' roles to each locator, this is not a good solution
>because the role then simply degenerates into a unique identifier (in which
>case it should be called id and not role).  Several examples where an arc
>between locators with the same role makes sense are shown below.

Well, it wouldn't actually degenerate to an ID, because the scope of roles
is *the same link*, not the document -- rather an important difference.

It seems to me that (as someone else also suggested) the application design
could benefit from some tweaking here. "Course" seems an ineffective choice
of role for link ends in the example your gave: it doesn't convey anything
about the role the link end plays in the link.

If your link is there to express the "prerequisite" realtionship, perhaps
the course being documented should have some role like "goal", and the
prerequisites some role like "prerequisite". If you label everything the
same, of course you can't distinguish them by label; but that's true of any
symbol system, not particularly XLink.

>
>     Given some set of college courses we want to show prerequisites.
>     Example with 'Normal' roles
>     <xlink:extended role='prerequisites'>
>       <xlink:locator href='/courses/cs101.xml' role='course'/>
>       <xlink:locator href='/courses/cs102.xml' role='course'/>
>       <xlink:locator href='/courses/cs201.xml' role='course'/>
>       <xlink:locator href='/courses/cs202.xml' role='course'/>
>       <xlink:arc from='course' to='course'/>
>     </xlink:extended>

Clearly you don't want arcs from 'course' to 'course', as you correctly
note. What you do want is links from the ends that serve one kind of role
(goal courses) to those that serve another (prereqs). If you use role to
mean the roles the ends play in the link (which is what I believe we
intend), I think you'll be fine.

>     But unless I am not understanding the current draft correctly, I need
>to assign a unique role to each of these in order to create the necessary
>relationships.

I don't see any reason for unique roles. if you make the role 'prereq',
your links will work just fine.

>     Another example which would require this would be children where you
>wanted to have younger-sibling or older-sibling relationship sets.

Same thing. Roles don't label a single Platonic role that is somehow the
essence of the link end apart from its participation in the link. They are
the role of the link end *with respect to* the link. Thus "children" would
only be a very useful role in links that express the parent/child
relationship (clearly a different relationship from sibling-hood; if you
wanted both represented in the same link, you'd want different roles for
each).

>
>Anyway, back to the implementation.  Obviously, the easy, if not so nice
>solution is to assign multiple roles to each locator depending upon the
>context of the linking situation.  Of course, this leads to duplicated
>storage space and greater implementation complexity.

The locator is not the link-end. A single link-end may well be referenced
from many links, via many locators. the role on any given locator is the
role the end plays in *that* link; which will obviously have to vary --
oone person's purpose in linking to a place may be totally unrelated to
another person's.


s

Steven_DeRose@Brown.edu; http://www.stg.brown.edu/~sjd
Chief Scientist, Scholarly Technology Group, and
   Adjunct Associate Professor, Brown University

Received on Friday, 21 January 2000 14:24:09 UTC