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

Pat Hayes wrote:

>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.

If I were forced to update an existing/in-use RDF-based system to treat
literal subjects, without changing the core of the system (for the moment at
least), the following idea comes to mind:

    1) The parsers and formatters would need to be extended to treat
generalized RDF syntax, and there would need to be some internal
representation of generalized RDF graphs. Ok, this would be some work to do,
but...

    2) Once I have an internal representation of generalized RDF graphs, we
can come up with a set of new URIs to replace all the "bad" literal subjects
with these URIs. There would be a table representing this replacement.

    3) Now, I can give the translated RDF to the original tool. The RDF is
fine now (conforming to RDF2004), and so the tool will work without
problems. The output of the tool would also be RDF2004 compliant. Because,
the tool, being a traditional RDF tool, won't introduce literals in subject
position itself.

    4) All output is then be re-translated to a generalized RDF form, by
substituting the special URIs with the original literals, and can be
presented as such by the new formatters (see 1).

There is certainly some code to write here, but most of it should be
straightforward to create and could be written once and made into an
open-source/free-software library to be used by everyone who needs it. And,
why shouldn't this library not be created by the RDF2 working group itself?

So, the "investment-killer" argument should not be a major one, at least...

Michael

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schneider@fzi.de
WWW  : http://www.fzi.de/michael.schneider
=======================================================================
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
=======================================================================

Received on Friday, 2 July 2010 10:01:28 UTC