vote up 4 vote down
star

It seems like RDFS/OWL (maybe also RIF?) inference is an important part of the Semantic Web. However, I don’t yet understand how it is supposed to be used in practice, when creating data consumers.

Suppose we have an application that inputs RDF data and searches it for all foaf:OnlineAccounts of a certain person. Naturally, these accounts may be of any rdf:type that is an rdfs:subClassOf foaf:OnlineAccount. And these classes are not limited to what FOAF itself provides: I could just as easily define my own ex:OnlineForumAccount. So it appears to me that the only reliable way to interpret such data would be to fetch all ontologies used in the input graph (by dereferencing some of the URIs) and then perform full inference, adding all resulting triples to the graph.

But is this really how people work, or are supposed to work, with RDF?

flag

3 Answers

vote up 2 vote down
check

It depends on what people want to do, there is no single recommended way how to work with RDF. Someone might want to do the full inference, someone might prefer faster queries, being aware that part of data will slip between his fingers.

Also another thing to have in mind is trust - someone could have ontology conflicting with some other, more established one.

link|flag
vote up 4 vote down

There is no "supposed".

If you run inference over the data then you will get more data, but especially in the FOAF world you will get some incorrect results if you do, and it will take a long time unless you have access to a lot of hardware.

My company has done some work with large amounts of FOAF and we did it completely without inference, but we do intelligently resolve Inverse Function Properties at runtime, using queries.

link|flag
1 
Steve, can you add a URL about what Inverse Function Properties are? – Egon Willighagen Nov 9 at 10:45
Egon, see w3.org/TR/2004/REC-owl-guide-20040210/… – Vasiliy Faronov Nov 9 at 14:02
vote up 2 vote down

In practice I use a specific query context for session specific inference rules. The process is either backward chained (engine evaluates the rules and returns a solution in the form of a result set) or constrained forward chaining (i.e., materialization of triples) e.g. by using SPARQL CONSTRUCT patterns.

Here is are some links that demonstrate what I describe above, using OpenLink Virtuoso, i.e., the effects of reasoning on "owl:sameAs" (co-reference and union expansion of all data across co-referents based on the URIs in the owl:sameAs relation) and/or doing the same in-directly via Inverse Functional Property relations:

  1. URIs that co-reference Michael Jackson in owl:sameAs relation
  2. URIs that indirectly co-reference Michael Jackson via an Inverse Functional Property relation (in this example "foaf:name" has been used to demonstrate the point via a context specific rule as per the indirect co-reference tab).

To actually see the union expansion in any of the views listed above, just use the "settings" link to enable "owl:sameAs" and/or one of the custom rules in the drop-down (pick "b3sifp") for the "foaf:name" Inverse Functional Property based rule demo.

link|flag

Your Answer

Get an OpenID
or

Not the answer you're looking for? Browse other questions tagged or ask your own question.