<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for bijan</title><link>http://disqus.com/people/7fff37d60ab249e59af486f8cdba1329/</link><description></description><language>en</language><lastBuildDate>Tue, 10 Oct 2006 04:42:53 -0000</lastBuildDate><item><title>Re: OWL 1.1</title><link>http://clarkparsia.disqus.com/owl_11/#comment-1446840</link><description>The Syntax and Overview links are live now, they are also attached to the email Peter sent annoucing them. (I'll email all the queriers about them to let them know).&lt;br&gt;&lt;br&gt;Re: justification. Er...why must there be 10 reasoners before we add features? Features aren't driven by implementations, but by use cases, and these extentions were all requested by users at the workshop. So that's the community drive. Believe me, no implementor wants to do these features because, by and large, they are not theoretically interesting. We won't be writing all that many papers about these (that aren't systems paper). Actually, that was perfectly clear in my post, so I don't understand, Danny, why you don't get it :)&lt;br&gt;&lt;br&gt;Besides, once you have two, if you don't want to fragment the community, you have to coordinate. We *are* a small enough community that we can coordinate the way we are doing. What's wrong with that? One reason we didn't move to an incubator group (well, ok, they weren't quite ready yet) is that we *want* to be as light weight as possible and try to grow the market (and the state of the art). It's possible that not all the features we develop here will make it into a W3C specification. (Maybe they'll turn out to be bad ideas, though I think only punning might have problems.)&lt;br&gt;&lt;br&gt;("Real" reasoners out there are Racer, Pellet, FaCT++, Cerebra engine, and KAON2...that I know of. 3 of these are commercially supported! All are under active development (well, KAON2 might see a hiatus, but I believe Boris intends to keep it going). This is indicative to me of a healthy market. That's up from 1 commercial one when OWL went to Rec and only 3 (Racer, Cerebra and the aging FaCT) when OWL started/went to last call/went to CR even, though Pellet might have been there by then in a preliminary form.) &lt;br&gt;&lt;br&gt;One other 1.1 task is to identify useful but tractable subsets of owl (e.g., the EL family, or DL Lite). I think this will spawn a new user community and several new implementations.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Thu, 22 Dec 2005 17:48:43 -0000</pubDate></item><item><title>Re: OWL 1.1</title><link>http://clarkparsia.disqus.com/owl_11/#comment-1446841</link><description>Re: utility. Two core features are simply obvious things that should have or almost are in OWL: Qualified cardinality restrictions and user defined datatypes. QCRs were in daml+oil and are &lt;em&gt;hugely&lt;/em&gt; important to bioinformatics applications (e.g., &lt;br&gt;"In contrast, a limitation in the expressive power of OWL-DL did cause con-&lt;br&gt;siderable problems: the lack of qualified number restrictions (also called qualified cardinality restrictions)." in &lt;a href="http://www.cs.man.ac.uk/~horrocks/Publications/download/2005/WBHL05.pdf" rel="nofollow"&gt;"A little semantics goes a long way in Biology"&lt;/a&gt;). Similarly, there are tons of requests for real user defined datatypes. In either case, the details are less important than agreement between the implemntors. &lt;br&gt;&lt;br&gt;The rest of the SROIQ stuff seemed both useful and easy. Having limited "triagnle" property composition gives you some useful "rule like" axioms.&lt;br&gt;&lt;br&gt;Given the minorness and the nice "rounding out" there was no reason not to add them.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Thu, 22 Dec 2005 18:09:01 -0000</pubDate></item><item><title>Re: OWL 1.1</title><link>http://clarkparsia.disqus.com/owl_11/#comment-1446843</link><description>I started replying point by point, but, eh, it's pointless. :)&lt;br&gt;&lt;br&gt;I don't see you've raised a remotely salient point: "web wide practical application" is not a pre-requisite for vendors to coordinate the support of their uses, which is what we did. There were over 60 people at the OWL Workshop and consensus was overwhelming for this course of action (there was &lt;em&gt;one&lt;/em&gt; person I recall expressing some similar meta qualms about it, and he participated with verve in the selection of things to go into 1.1.) So, we have users...why shouldn't we support them? In contrast, you don't seem to be an OWL user...why should I worry about your qualms? You don't see a need for the expressiveness, a load of other people do.&lt;br&gt;&lt;br&gt;I find your dismissal of the &lt;em&gt;number&lt;/em&gt; of implementations as indecent just silly. I don't know what else to say about that. There are three companies selling OWL reasoners and two open source implementations. All of these are independently developed.&lt;br&gt;&lt;br&gt;As for making it more confusing for non-expert application implementers...how so? If you are an ontology developer, learn the new features and use them if you need them. If you don't need them, don't use them. Really, this just seems to be a non sequitur.&lt;br&gt;&lt;br&gt;In case it isn't clear, I'm not remotely swayed by your qualms. So don't bother repeating them :) I have been somewhat swayed by worries that calling it "OWL 1.1" (or OWL 2.0) might slow adoption because it makes it seem like OWL isn't finished. That's one reason for &lt;em&gt;not&lt;/em&gt; taking it to a standards body (yet). This is just users and implementors getting together...what's the harm?&lt;br&gt;&lt;br&gt;(I don't buy the slow adoption argument, though I don't have conclusive evidence either way. I've heard people argue that &lt;em&gt;not&lt;/em&gt; adding stuff slows adoption because it makes OWL seem stagnant. I know it slows adoption by people who need more expressiveness.)&lt;br&gt;&lt;br&gt;(It would be interesting to shift it into an incubator group. I'm not sure it's the best idea. The other point is that we wanted this to be &lt;em&gt;very&lt;/em&gt; lightweight and inexpensive, whereas a normal working group is very expensive. An incubator group might be as cheap as an Oasis TC, which would be reasonable.)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Fri, 23 Dec 2005 00:18:35 -0000</pubDate></item><item><title>Re: Merry War on Xmas</title><link>http://clarkparsia.disqus.com/merry_war_on_xmas/#comment-1446854</link><description>Aditya and I, in IM, arrived at a different version for Season's Greetings.&lt;br&gt;&lt;br&gt;(Assume bijan and you are logical constants...replace with the appropriate parties)&lt;br&gt;&lt;br&gt;&lt;blockquote&gt;For all x, y such that Holiday(x), OccursAfter(x, dec 1), OccursBefore(x, jan 2), greetingFor(y, x), wishes(bijan, you, y)&lt;/blockquote&gt;&lt;br&gt;&lt;br&gt;I suspect the start date is a bit flexible (e.g., Dec 12 is prolly fine, may even be better). To make this into Happy Holidays, you need to kill he greetingFor, then muck with the wishes operator...which really isn't a predicate, but a propositional attitude. So we have an intensional structure no matter what.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Fri, 23 Dec 2005 12:26:37 -0000</pubDate></item><item><title>Re: Merry War on Xmas</title><link>http://clarkparsia.disqus.com/merry_war_on_xmas/#comment-1446855</link><description>Good point, Jordan. It's probably the case that you aren't meant to be doing &lt;em&gt;all&lt;/em&gt; for &lt;em&gt;everyone&lt;/em&gt;, but the appropriate ones for each. I think I still tend to think of them as substitutes for "Merry Xmas and Happy New Year", which is what they replaced for me. How Xmas centric of me! Maybe not...I think everyone gets a Happy New Year.&lt;br&gt;&lt;br&gt;So, to update the updated one:&lt;br&gt;&lt;br&gt;&lt;blockquote&gt;For all x, y such that Holiday(x), OccursAfter(x, dec 1), OccursBefore(x, jan 2), holidayFor(x, you), greetingFor(y, x), wishes(bijan, you, y)&lt;/blockquote&gt;&lt;br&gt;&lt;br&gt;Or to get more in touch with my inner me:&lt;br&gt;&lt;br&gt;&lt;blockquote&gt;For all x, y such that Holiday(x), OccursAfter(x, dec 1), OccursBefore(x, jan 2), holidayFor(x, you), notLoathedBy(x, bijan), greetingFor(y, x), wishes(bijan, you, y)&lt;/blockquote&gt;&lt;br&gt;&lt;br&gt;Add your own codicil (e.g., notInvolvingAnimalSacrafice(x), etc.)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Fri, 23 Dec 2005 12:35:21 -0000</pubDate></item><item><title>Re: OWL 1.1</title><link>http://clarkparsia.disqus.com/owl_11/#comment-1446845</link><description>I think you are wrong. I think you shouldn't expect to sway me because your arguments are either unfounded or vague. Actually, they are pure FUD, which is why they torque me off :) We switched to the 1.1 label to mitigate fears, but really, if you are all bent out of shape by that label..pfft. I'm not against marketing but the semantic web has far graver marketing problems than this. Plus, a user driven, vendor supported effort is exactly the kind of things one would expect to see.&lt;br&gt;&lt;br&gt;I see while you don't mention it, you do drop the "not a decent number of implementations". What &lt;em&gt;is&lt;/em&gt; the decent number, btw? Do you have ANY criteria to offer for when we can make moves? I mean, this &lt;em&gt;isn't&lt;/em&gt; an immediate standardization effort. It's preliminary.&lt;br&gt;&lt;br&gt;I don't fear the label.&lt;br&gt;&lt;br&gt;As for your last three sentence, well, they are offensive. The "insight" of a self-selected active web developer who believes the SW vision is a very good idea may not reflect the requirements of the Semantic Web &lt;em&gt;either&lt;/em&gt;. We tried to reach out to a broad community. Our process was, and continues to be, open. We intend to gather experience.  We intend to submit a note to the W3C. We are working &lt;em&gt;against&lt;/em&gt; fragmentation.&lt;br&gt;&lt;br&gt;The Semantic Web isn't a person or even an institution. It doesn't have requirements. Grr.  What a BOGUS dialectical move. I spend a great deal of my time thinking about the Semantic Web, why would you think we &lt;em&gt;wouldn't&lt;/em&gt; consider these things? Or are we just dumber than you? Where's &lt;em&gt;your&lt;/em&gt; reality check?&lt;br&gt;&lt;br&gt;I notice too that you completely ignored the vendor support.&lt;br&gt;&lt;br&gt;Ok, I'm ticked and should stop. It's perfectly fine to have concerns. It's theoretically possible that the OWL 1.1 effort will kill the Semantic Web, the Web itself, and life as we know it. But I don't think so, and in the absent of more specific evidence, I think it's fair to put such worries aside.&lt;br&gt;&lt;br&gt;(Oh, if you want another driver, datatypes are definitely key. We will hit a roadblock in supporting Web Services policy languages without better numerics. Our &lt;a href="http://www.mindswap.org/2005/services-policies/" rel="nofollow"&gt;reduction&lt;/a&gt; of WS-Policy to OWL has spurred more interest in OWL from the Web Services guys than anything else I know of.)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Fri, 23 Dec 2005 12:56:23 -0000</pubDate></item><item><title>Re: OWL 1.1</title><link>http://clarkparsia.disqus.com/owl_11/#comment-1446846</link><description>BTW, you are, of course, welcome to attend the next OWL Experiences and Directions workshop next year, which will, again, be colocated with ISWC. And feel free to join the mailing list. I think you will be more effective if you take a less generally naysaying attitude, and be more precise in your qualms and their basis, but, eh, up to you.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Fri, 23 Dec 2005 12:58:58 -0000</pubDate></item><item><title>Re: OWL 1.1</title><link>http://clarkparsia.disqus.com/owl_11/#comment-1446848</link><description>Fair enough. There are risks, but I think the risks are greater in inaction in this matter. I'm certainly open to my being wrong wrong wrong, though I tend not to predict it.&lt;br&gt;&lt;br&gt;Currently there's a &lt;a href="http://lists.mindswap.org/pipermail/owl/2005-December/000121.html" rel="nofollow"&gt;debate&lt;/a&gt; on the &lt;a href="http://lists.mindswap.org/mailman/listinfo/owl" rel="nofollow"&gt;list&lt;/a&gt; about whether a more "modular" OWL 1.1 spec is a good idea...again it's all marketing. I personally (as you can see) think it's a terrible idea. I've gotten pretty grumpy about it, but hey, I'm a grumpy guy.&lt;br&gt;&lt;br&gt;I think catering to the bioinformatics folks is a v. good thing. Having &lt;a href="http://obo.sourceforge.net/" rel="nofollow"&gt;OBO&lt;/a&gt; in OWL is a great tractor app, and if we can attribute a drug discovery or two to OWL ontologies...well, &lt;em&gt;that's&lt;/em&gt; a great selling point.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Fri, 23 Dec 2005 17:37:16 -0000</pubDate></item><item><title>Re: Forthcoming SPARQL tutorial</title><link>http://clarkparsia.disqus.com/forthcoming_sparql_tutorial/#comment-1446852</link><description>Dude, get a better login in name.&lt;br&gt;&lt;br&gt;I hadn't planned to say anything about SADDLE, but given there is another query language tutorial, I might shift more to the protocol. I think the query language is easier to academe about, so I have a preference in that direction.&lt;br&gt;&lt;br&gt;If something picks up twixt now and the school (I have materials due in like Feb and/or May) or you have some ideas on what to cover, I'd be happy to include it.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Fri, 23 Dec 2005 17:39:05 -0000</pubDate></item><item><title>Re: Merry War on Xmas</title><link>http://clarkparsia.disqus.com/merry_war_on_xmas/#comment-1446859</link><description>I'll note that the fact of jen's post contradicts what jen said in that post! I was actually studying such sentences in my prior thesis topic.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Fri, 23 Dec 2005 22:05:38 -0000</pubDate></item><item><title>Re: 5 Best Semantic Web Tools</title><link>http://clarkparsia.disqus.com/5_best_semantic_web_tools/#comment-1446861</link><description>FaCT++ is open source and certainly &lt;a href="http://www.mindswap.org/2003/pellet/performance.shtml" rel="nofollow"&gt;faster&lt;/a&gt; for many things.&lt;br&gt;&lt;br&gt;I'm not a huge Kowari fan...no RDFS and it seems a bit of a PITA to get working. Another category that could be interesting is "lightweight, simple" RDF stores. I.e., for small projects where you just want to read in an RDF/XML file process it, and dump something.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Wed, 28 Dec 2005 10:28:00 -0000</pubDate></item><item><title>Re: Varieties of RIF</title><link>http://clarkparsia.disqus.com/varieties_of_rif/#comment-1446879</link><description>I so choose because of your fearless leadership :)&lt;br&gt;&lt;br&gt;Thanks for the Lifschitz link. I wanted one of his, but at that time of night my googling failed me.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Mon, 23 Jan 2006 03:25:29 -0000</pubDate></item><item><title>Re: 5 Best Semantic Web Tools</title><link>http://clarkparsia.disqus.com/5_best_semantic_web_tools/#comment-1446874</link><description>FaCT++ is actually now all of SHOIN, thus (depending on datatype support) all of OWL-DL. It's ABox support is weak though and it doesn't (yet) have any optimizations for nominals.&lt;br&gt;&lt;br&gt;Pellet does not (yet) support *qualified* cardinality, alas. Soon we hope. Pellet does support nominals with a lot of optimizations and nice ABox support (including conjunctive query). Not to mention all the debugging features (though some of them are reasoner independent).&lt;br&gt;&lt;br&gt;Re: Protege over SWOOP...what can I say, when you're wrong you're wrong ;)&lt;br&gt;&lt;br&gt;Ok, I hate using Protege and and a main force behind Swoop, so I'm biased. If we can get Swoop stable, I think both the functionality and the usability blow Protege out of the water. (For OWL, at least.)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Sun, 29 Jan 2006 23:57:01 -0000</pubDate></item><item><title>Re: The use of OWL</title><link>http://clarkparsia.disqus.com/the_use_of_owl/#comment-1446885</link><description>In relpy to Yarden: I say I don't want an answer derived from the network effect because we don't (largely) &lt;em&gt;have&lt;/em&gt; a suitable network effect, and it's not clear that without first order benefits that we're &lt;em&gt;right&lt;/em&gt; to encourage adoption based on second order benefits. At least, it's ungrounded, especially in the presence of other things that already have the second order benefits, nigh overwhelmingly.&lt;br&gt;&lt;br&gt;(Of course, there are relative arguments. If someone wanted to work with SHIF ontologies, I would not recommend that they use KRSS syntax instead of OWL RDF/XML syntax...the latter has advantages solely from it being a standard even though, in many ways it's a technical PITA.)&lt;br&gt;&lt;br&gt;I don't think I said that "representing and reasoning with partial information" &lt;em&gt;is&lt;/em&gt; the application, just that (for certain ranges) that's what OWL does well, so any app (e.g., configuration) which requires that is a good candidate for OWL.&lt;br&gt;&lt;br&gt;People regularly ask for &lt;em&gt;more&lt;/em&gt; expressive power (e.g., OWL 1.1)...so I don't see your point. Obviously, if you can't represent something in OWL due to some other limitation (e.g., you need role value maps) then OWL doesn't help you, but I don't think I suggested otehrwise.&lt;br&gt;&lt;br&gt;Also, I'm not trying to distinguish OWL from other similar logics, but OWL from e.g., "webized Datalog" or XML. Where does the &lt;em&gt;particularly&lt;/em&gt; expressivity help? What is it good for, in general? Of course, I appeal to traditional DL applications, because those are known. We can see how something like OWL would help with them.&lt;br&gt;&lt;br&gt;I'm not trying to speculate...I'm trying to help people acquire a concrete understanding of what you could sensibly use OWL for.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Tue, 21 Mar 2006 18:12:24 -0000</pubDate></item><item><title>Re: SPARQL Tutorial slides</title><link>http://clarkparsia.disqus.com/sparql_tutorial_slides/#comment-1446890</link><description>Thanks for the feedback and compliments.&lt;br&gt;&lt;br&gt;Two positioning points: The slides are not meant to be stand alone, and the target audience is an intensive summer school for graduate students working in the area. Now, many may just be &lt;em&gt;starting&lt;/em&gt; to work in the area, so I'll find out how well I've aimed this on Monday. (I'm also first on the billing, oy!)&lt;br&gt;&lt;br&gt;I hope these ameliorate the Oedipus example. I like it because it's a great example of reasoning by cases, and, really, it's not that hard to understand. Plus, it has that nice classical flavor!&lt;br&gt;&lt;br&gt;As for FOAF and SIOC (what's that?) data, I'm not so sure where you think they would have extra force. Do you mean instead of Oedipus? (But then they wouldn't illustrate the difference between distinguished and non-distinguished variables very nicely.) Or do you mean instead of my :mochi examples (which seem harmless).&lt;br&gt;&lt;br&gt;It would be nice to have better integration with live demos (in fact, I almost did that with the Pellet web demo), but, in the end, for slides, it seemed a little tricky to get it right (and I was way overdue with the slides!) If I do something like this again, I'll try to play more with that.&lt;br&gt;&lt;br&gt;Also, in the end, it's not really a tutorial about how to use SPARQL, but more about how to think about (only some of!) the challenges of RDF query langauges. There are loads more than I touched on, alas. The account of the semantics is woeful, indeed, in part because we don't have a good theoretical understanding nicely worked out and settled. Shocking, isn't it!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Wed, 30 Aug 2006 21:00:18 -0000</pubDate></item><item><title>Re: webMethods acquires Cerebra (and I play with Diigo)</title><link>http://clarkparsia.disqus.com/webmethods_acquires_cerebra_and_i_play_with_diigo/#comment-1446892</link><description>I have no idea what point you intend to make or what conclusions you think I made that need correction.&lt;br&gt;&lt;br&gt;webMethods bought Cerebra. The Cerebra team are now employee's of webMethods. webMethods clearly owns most of the Cerebra IP, etc. etc.&lt;br&gt;&lt;br&gt;The article I ripped apart is still completely silly.&lt;br&gt;&lt;br&gt;Make a cogent point, or really, any point. BTW, "substantively all assets" is just legal speak. It's perfectly reasonable to say, "webMethods bought Cerebra". Indeed, everyone &lt;em&gt;is&lt;/em&gt; saying that.&lt;br&gt;&lt;br&gt;Hmm. Your post could use a nice snarky deconstruction as well :)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Mon, 04 Sep 2006 20:14:38 -0000</pubDate></item><item><title>Re: Not the lightweight crayons!</title><link>http://clarkparsia.disqus.com/not_the_lightweight_crayons/#comment-1446881</link><description>The link for MYCIN should be to &lt;a href="http://en.wikipedia.org/wiki/Mycin" rel="nofollow"&gt;http://en.wikipedia.org/wiki/Mycin&lt;/a&gt;.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Mon, 18 Sep 2006 12:02:37 -0000</pubDate></item><item><title>Re: webMethods acquires Cerebra (and I play with Diigo)</title><link>http://clarkparsia.disqus.com/webmethods_acquires_cerebra_and_i_play_with_diigo/#comment-1446896</link><description>You missed "scarquote". Diigo was a bit annoying and I forgot to do a spelling check at the end. Sigh.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Tue, 10 Oct 2006 04:41:00 -0000</pubDate></item><item><title>Re: NLTK: NLP in Python</title><link>http://clarkparsia.disqus.com/nltk_nlp_in_python/#comment-1446898</link><description>Thanks for the links! I'll check them out.&lt;br&gt;&lt;br&gt;I'm aware of the difference and what seems to be the current preferred approach (stats). &lt;br&gt;&lt;br&gt;The commonsense based one looks absolutely fascinating! And very useful for my current class. Thanks again.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">bijan</dc:creator><pubDate>Tue, 10 Oct 2006 04:42:53 -0000</pubDate></item></channel></rss>