1. 1
  1.  

  2. 2

    This is sort of the tension between a properly one fact one place, normalized database and the need “JOIN” all the tables together before you can query.

    The trouble with “semantic locality” is it is inflexible. It makes it trivial to answer the one question for which you have it, and very hard to answer the others.

    That said, if you only have one question and/or you very seldom need to update the info…. yup, “semantic locality” is great.

    1. 1

      Well, it is also a useful feature of a report generated from the database — by definition, a report should not be updated but regenerated, and it can afford being single-use.

      I have at some point written a shell script that generates and RDF file, asks a SparQL engine to summarize it, then does some more processing on the output. I would agree with the author that semantic locality is a useful property to consider and have in some parts of the system — when doing explicitly non-local things, essential non-locality of a piece of work can be one of the criteria for choosing the joints to carve.