- From: William Waites <ww@styx.org>
- Date: Tue, 18 Jan 2011 22:30:04 +0100
- To: Ivan Mikhailov <imikhailov@openlinksw.com>
- Cc: Harry Halpin <hhalpin@ibiblio.org>, Semantic Web <semantic-web@w3.org>
* [2011-01-19 01:48:27 +0600] Ivan Mikhailov <imikhailov@openlinksw.com> écrit: ] Virtuoso deals with owl:sameAs in a scalable way, so you can try. Of ] course, a single chain 50 million connections long would cause problems, ] but more traditional cases should work fine. Google for "virtuoso ] owl:same-as input:inference" may be the fastest way to get more hints. Maybe I'm doing something wrong but in my experience Virtuoso's owl:sameAs handling is not great. For example in bibliographca we have, foo a bibo:Book ; dc:contributor [ foaf:name "Bob"; owl:sameAs <http://some/author> ]. When the http://some/author is dereferenced it will first look for graph named that in the store. If it doesn't it goes and asks the store for all triples that have that as a subject with sameAs processing turned on (would be nicer to have a bnode closure, actually). If there are many books that have contributor sameAs that (where many is maybe 50) the query takes too long and times out. At this stage I would not recommend using Virtuoso's sameAs processing and am going to materialise these graphs... As far as strategies for dealing with sameAs are concerned, I've been meaning to do some experiments regrouping them into a congruence closure or bundle as its sometimes called, then doing things like migrating all properties from the leaves to the root. Some preprocessing that worked like that would bake a database structure that was much easier to work with instead of trying to solve things by implementing the formal definition directly (and recursively!). Cheers, -w -- William Waites <mailto:ww@styx.org> http://eris.okfn.org/ww/ <sip:ww@styx.org> F4B3 39BF E775 CF42 0BAB 3DF0 BE40 A6DF B06F FD45
Received on Tuesday, 18 January 2011 21:30:33 UTC