Most Popular Stories
eBooks, Webcasts, Whitepapers and More
Whitepaper: Linux Adoption in a Global Recession. Sponsored by Novell
Analyst Report: Linking Decisions and Information for Organizational Performance
eBook: The Current State of ITIL. Sponsored by IBM
Whitepaper: Top 10 Things to Look for When Choosing an Infrastructure Provider. Sponsored by Verio
Whitepaper: Put ITIL Best Practices To Work. Sponsored by IBM
Partners
The Semantic Question: To Delete or Not To Delete
A few months back I posed a question to the folks at DERI (Digital Enterprise Research Institute) from the University of Ireland when they came to visit Radar Networks. This is a question that I have struggled with for a long time; seeking for answers anywhere I could. When I asked them, I heard the same question in response that I always hear.Why? Why would you ever want to delete something out of the ontology?
Ontologies were not originally created to have things removed from them. They were created to classify and organize information in a relational format. Just because a species goes extinct it doesnt mean it should removed from the domain of animals does it? Just like a car that isnt manufactured anymore or a disease that was officially wiped out. These and many more are probably the reasons why Semantic Web gurus and ontologists alike dont like the idea of deleting entities.
I am helping to create a social site where users generate content; objects, notes, data, and connections to others and other things that are their own. If they want to delete something that they have created, so be it. Sounds easy right? Well, yes and no. This problem is dealt with throughout computer systems. It is essentially all about managing pointers in memory. You cant delete something that other things are pointing to. Who knows what will happen or how our application will respond when certain pieces of information are missing? Some things we account for on purpose because they are optional -- but some things we just cant. Every application has its unique constructs, whether it is built on a relational database or a triple store.
So what I have to do is define ontological restrictions, stating what links can and cannot be broken. On top of that, we must worry about permissions. Am I allowed to break an object link from someone else's object to my own? Also, what if the object being deleted has dependent objects that cannot exist alone, or more importantly, don't make sense on its own? A great example of this is a user object and a profile object. There should either be zero or two, never just one.
My friend and coworker Jesse Byler had dealt with a similar problem in the application tier a few months back regarding dependent objects. He had written a recursive algorithm that would spider the graph until it hit the lowest leaf node matching certain criteria and then begin to operate. I took this same principle and pushed it down into our platform and began to mark restrictions in our ontology.
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.

With the release of ITIL v3 come many questions from IT managers and CIOs. Most common among them: "What's the difference between v2 and v3?" and "Should I wait to start my ITIL project?" This Internet.com eBook offers expert advice to help technology executives answer these questions and more. Read more.