Re: Show me the money - (was Subjects as Literals)

Excellent point!

I can easily come up with examples where current SPARQL capabilities are too limiting or where atomic list nodes would tremendously help. But for literals-as-subjects, I do not see the need. It might also depend on how you interpret RDF:
(1) A triple is an element in a relation/predicate and thus loosely similar to a Prolog fact. It just so happens that the predicate is written infix.
(2) A triple describes a property of a resource, the resource is the dominant conceptual element

For (1), literals make sense, just for the sake of symmetry. For (2), they do not make sense, because identity becomes an issue. Well, this might just be my intuition, so I might be wrong.

As for the cost: Some improvement will eventually be made to RDF. Can we find a way to version the currently used standard? Loosely related, the transition from HTTP 1.0 to HTTP 1.1 seemed to have gone smoothly and they always include versions.

Axel

On Jul 1, 2010, at 18: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
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 
> -- 
> John S. Erickson, Ph.D.
> http://bitwacker.wordpress.com
> olyerickson@gmail.com
> Twitter: @olyerickson
> 
> 

-- 
Dr. Axel Rauschmayer
Axel.Rauschmayer@ifi.lmu.de
http://hypergraphs.de/
:: Hyena: connected information manager, free at hypergraphs.de/hyena/ ::

Received on Thursday, 1 July 2010 16:20:49 UTC