Backward and Forward links in RDF just as important
Piet Hein, I think, Grooked that,
"Two types that had far better leave to their betters
the civilized art of exchanging letters
are those who disdain to make any response,
and those who infallibly answer at once!"
The regularity of this blog fails on both counts.
One meme of RDF ethos is that the direction one choses for a given property is arbitrary: it doesn't matter whether one defines "parent" or "child"; "employee" or "employer". This philosophy (from the Enquire design of 1980) is that one should not favor one way over another. One day, you may be interested in following the link one way, another day, or somene else, the other way.
On the other hand, also one should not encourage people having to declare both a property and its inverse, which would simply double the number of definitions out there, and give one more axis of arbitrary variation in the way information is expressed. Therefore, the design of the tabulator was is to make the system treat forward and backward links equivalently.
The design of N3 also was influenced by this. The ability to write
:Joe is f:parent of :Fred.
makes it easier to write (or generate) N3 without having to use f:child. This in turn reduces the pressure to define both.
The only loss in not having both is that there is no label for the reverse link. (In same cases I have defined an unnamed predicate which is delcared as the inverse and has a label.)
Let's separate the inverse of a link, that is, the property which would have the meaning of a link in the opposite direction, from a reciprocal link.
If a link links x and y, and is stored on the document you get at x, then by reciprocal link I assume you mean the same information stored at y. Of course, this only makes sense when x and y derefence to different documents. Reciprocal links are important for browsable RDF, but they are not always a good idea, and sometimes they aren't defined (e.g. when the link between x and y is stored at z).
If you store the same information on both documents, you can of course use the same property. Just because x is the URI which derefs to this document doesn't mean it has to be the subject of all the links -- it can be the object. I am saying let's stick to using, say foo:parent, whenever the relation is given, and in whichever document it is given.
It is really important that the form the RDF arcs take is not dependent on where the information is stored. Who is making the connection is connected with where the link was found, not how it is written.
During development of user interfaces, we noticed that it is hard to visualize backlinks. Good old Enquire required an inverse for everything.
For the sake of good querying and visualizing, an inverse is often needed, a little inference can then get me the other triple (child/parent).
Was also noticed by Jean Rohmer here. Hence I would love to see the possibility of inverseProperty on the level of RDF(S).
The xml topic map people use the label of the association to
label the relation in user interfaces, which is a kind of hack to avoid it.
I spend a lot of my time trying to convince corporate users of the benefits of the SW.
One of the features they really appreciate and see the value of is biderectional linking.
The rule we have been using to manage the naming is to have an optional tag to the relationship (reverse) that can be populated. If it is empty the system uses the forward name with a visual indicator that it is reverse.
I completely agree that reverse links are essential. I also agree with connolly and prefer
:Fred f:parent :Joe.
As for the last part, why not defining rdfs:reverse-label? Consider:
f:parent rdfs:label "parent"; rdfs:reverse-label "child".
Alexander, this is already defined in OWL. See http://www.w3.org/TR/2004/REC-owl-features-20040210/#inverseOf for details.
David, thanks for pointing this out. I have had the same idea as well, but imagine we have:
:Fred :use :pen.
:use rdfs:label "uses".
While we may define:
:use owl:inverseOf :isUsedBy.
:isUsedBy rdfs:label "is used by".
I thought it is overkill to define inverse resources just for human-readable labels in some cases.
But for parent-child relashionship, you're absolutely right -- owl:inserveOf is the right thing to do.
Well, you can define the inverse label without having to define a URI for the inverse label, of course. Use a bnode:
use owl:inverseOf [ rdfs:label "is used by"].
"use has an inverse whose label is 'is used by'."
This directionality stuff prompted me to write an item about frbr:embodimentOf a couple weeks ago. I very much prefer the RoleNoun pattern over that HasPropertyOf stuff.
As mentioned in a development discussion of my RDF Relations module for Drupal, mainly on the topic of actual metadata storage methods,
I think although a document may be aware of reciprocal links, it's not the targets job to be able to edit them.
All links are one-way! some of them are implicitly two-way but thats a job for the ontology. Think Friend-of-a-friend - I may claim you as a friend, but IsAFriendOf may not be a relationship you want to have!
If a link is reciprocal (it has an inverse) I could have automatically defined that too, but I don't need to fill up the database with that stuff yet, if I can avoid it.
I need to find a balance between doing extra lookups and keeping track of extra data. I want to keep statements about items attached as near as possible to their items. Each chapter IsPartOf a book, but the book itself doesn't need to maintain a list of all HasParts when the information can be implicitly retrieved with a query. I feel that info is best stored as a property of the smallest item.
Although those two statements (isPartOf/hasParts) tell me the same thing, the semantic wording can be said to be subtly different. I wish to retain that, in order to retain control (and knowlege of) who's making the connection.