How to create reusable predicates (RDF)?

Viewed 82

Complete RDF newbie here, and I am struggling to understand how to create sensible and reusable predicates. I asked a couple of experts at our company, but their predicates were (forced to be) unique by duplicating the object (e.g. woman,has_a_bag,purse vs woman,has_a,purse).

Here's a concrete, but simple, example of my problem:

man, has a, watch

car, has a, tire

bird, has a, feather

In Protege, not only does the car have a tire, it also has a feather and watch because of the common/shared predicate. If I have to make a unique predicate for each subject/object pairing, it would seem to invalidate the value of RDF. So, I am certain that I am doing something very wrong.

Thanks!

1 Answers

Well, what you have here is certainly technically possible as an RDF model. Your modeling, using the same "has a" predicate for all the different types of relations you are expressing, is not dissimilar from creating an SQL table as follows:

     thing |  has_a
  ---------|-----------
    man    |  watch
    bird   | feather
    car    | tire

The question is whether representating your data in this fashion is useful to you. If your goal is to only answer queries like "give me all things and the things they have" then yes. But presumably you will want to know more, and query more specific questions.

Another thing to keep in mind is that you're not being very precise about what the relation is actually. You say that "man has a watch". Does that mean a man owns a watch, or currently has one in his pocket? What about birds and feathers? Do birds "have" feathers in the sense of owning them, or being composed of them, or something else?

A large part of the reason you're struggling is that your examples are not precise enough to really express what you mean - not just with the name of the relation, but also with the subject and the object, by the way: do you mean to say that all men have watches, or that one particular man has watches, or that one particular man has one particular watch, or something else? The reason I point this out is that when you start drilling down into this, and trying to become precise about what you're trying to express in your RDF model, it often becomes much more clear what the precise, meaningful, unique names for your relations should be.

Related