Jeremy, your argument is perfectly sound from your company's POV, but
not from a broader perspective. Of course, any change will incur costs
by those who have based their assumptions upon no change happening.
Your company took a risk, apparently. IMO it was a bad risk, as you
could have implemented a better inference engine if you had allowed
literal subjects internally in the first place, but whatever. But that
is not an argument for there to be no further change for the rest of
the world and for all future time. Who knows what financial
opportunities might become possible when this change is made,
opportunities which have not even been contemplated until now?
It is also important to distinguish changes which actually harm your
code, and changes which simply make it less complete. Allowing literal
subjects will not invalidate your engines in any way: it will simply
mean that there will be some RDF out there which they may be unable to
process, or which might require them to do some preprocessing (such as
replacing
<literal> :p :o .
with
_:x :p :o .
_:x :same <literal> .
with a special company-specific :same property marker. For example.)
But none of this *invalidates* your huge pile of expensive investment
in code base; it merely makes it just a wee bit obsolete. But by the
time this process is over, it will be obsolete anyway, I am sure,
simply by virtue of being about four or five years older.
Best wishes
Pat
On Jul 1, 2010, at 10:38 AM, 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.
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.
It is a no brainer not to do the fix even if it is technically correct
Jeremy
------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 mobile
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
