This is where it became tricky. Some relationships are bi-directional and some are not. In the user and profile example above the relationship is bi-directional; however, many of our relationships are not. An example to this would be a group and an invitation to that group. Sure the group can exist without invitations, but the invitation cannot exist without the group.
All in all, the design pattern isn't overly complex, nor are the ontological restrictions. But as a whole, it makes for an interesting problem with a lot of nuance. Careful consideration must go into this process because mistakes could be catastrophic. Data integrity is paramount and dangling references could leave the application in a terrible state due to one bad linkage. Although simple in practice, the execution is anything but.
And for those of you who are still asking yourselves why?
Here's the answer. Scalability. As if working with a triple store wasn't hard enough, keeping useless data around that will never be used again will definitely make matters worse. We are attempting to build a practical everyday application -- not classify organisms. Surely there is a place somewhere in the mind of the ontologist where he can think practically about using ontologies for data storage. Isn't there?
As more applications are built using OWL and RDF, this problem will become more and more real -- and there's nothing the ontologist can do about it but adapt, or die a little inside. Either way, at the end of the day, I am still an engineer trying to make do with what I have.
If we must delete, then so be it.
John Clarke Mills is an application engineer at San Francisco startup Radar Networks, attempting to bring the Semantic Web to life with their first commercial product, Twine.com. Twine is a new service that helps you organize, share, and discover information about your interests, with networks of like-minded people. Before coming to Radar, John began his career as an engineer for CNET Networks.
IE 7
Firefox 2.0
