- From: Robert Fuller <robert.fuller@deri.org>
- Date: Thu, 01 Jul 2010 17:30:23 +0100
- To: Linked Data community <public-lod@w3.org>
Saw them, smiled, threw them in the bin. I can't present a use case for "Literals as Subject", but I did have a relevant experience recently when having written a reasoner for sindice I was briefly intrigued to discover that executing some owl rules leads to a production of statements where literals appear in the subject position. As the reasoner was written primarily with performance and memory constraints in mind, it never occurred to me to investigate whether the principles of rdf inferencing prohibit generating such statements. But since triples with literal in the subject position are currently not of any interest to us, we simply discard them during a filtering phase. Kind regards, Robert On 01/07/10 17:05, John Erickson wrote: > RE getting "a full list of the benefits," surely if it's being > discussed here, "Literals as Subjects" must be *somebody's* Real(tm) > Problem and the benefits are inherent in its solution? > > And if it isn't, um, why is it being discussed here? ;) > > On Thu, Jul 1, 2010 at 11:46 AM, Henry Story<henry.story@gmail.com> wrote: >> Jeremy, the point is to start the process, but put it on a low burner, >> so that in 4-5 years time, you will be able to sell a whole new RDF+ suite to your customers with this new benefit. ;-) >> >> On 1 Jul 2010, at 17:38, Jeremy Carroll wrote: >> >>> >>> I am still not hearing any argument to justify the costs of literals as subjects >>> >>> I have loads and loads of code, both open source and commercial that assumes throughout that a node in a subject position is not a literal, and a node in a predicate position is a URI node. >> >> but is that really correct? Because bnodes can be names for literals, and so you really do have >> literals in subject positions.... No? >> >> >>> Of course, the "correct" thing to do is to allow all three node types in all three positions. (Well four if we take the graph name as well!) >>> >>> But if we make a change, all of my code base will need to be checked for this issue. >>> This costs my company maybe $100K (very roughly) >>> No one has even showed me $1K of advantage for this change. >> >> I agree, it would be good to get a full list of the benefits. >> >>> >>> It is a no brainer not to do the fix even if it is technically correct >>> >>> Jeremy >>> >>> >> >> >> > > > -- Robert Fuller Research Associate Sindice Team DERI, Galway http://sindice.com/
Received on Thursday, 1 July 2010 16:31:02 UTC