Re: Why skolemization?

If someone has not done so already, I suggest creating an ESW wiki page
for collecting requirements.  I also think we should consider
non-skolomizing solutions that would meet the requirements.


On Sat, 2011-03-26 at 17:07 +0000, Nathan wrote:
> Nathan wrote:
> > Sandro Hawke wrote:
> >> Skolemization.
> > 
> > Sorry, but can somebody clarify why we, or RDF, needs Skolemization? Is 
> > this to cover a data management problem particular to a certain way of 
> > storing RDF data?
> Just to save a little bit of time, I do understand the problem to some 
> extent (although I'd like it spelled out clearly and people to agree 
> with the problem statement), my primary concerns/thoughts are:
> 1) Forcing a solution which doesn't apply across the board, for example 
> to those using flat file storage (human managed), or saving in object 
> tree structures (no bnode identifiers typically, just anonymous 
> nodes/objects). As in, introducing at RDF level to cover a problem which 
> doesn't exist at RDF level.
> 2) Temporal nuances, let's say a bnode is skolemized/named at time1 as 
> "xyz", then removed at time2, then at time4 a new bnode is 
> skolemized/named with "xyz", somebody who only has a serialization from 
> time1 and time4 would consider them the same. (hope I explained that 
> properly)
> 3) If using any form of URI, then this is still an RDF URI Reference, so 
> why not just use normal (say http) URIs.
> 4) RDF either needs blank nodes, or not, if it does, then blank node 
> identifiers are either needed in serializations or not, and then on the 
> next level we have management of data which includes blank nodes - it 
> would be nice if each of the three levels where cleanly separated and 
> agreements made with respect to each. (general application of separation 
> of concerns to this discussion).
> 5) If one were to look at how we name things in RDF, starting from 
> scratch, what would be the "perfect" approach? perhaps identifying this, 
> then seeing if it can be used, or working out steps towards, or 
> incorporating what was learned, would be beneficial. For example I've 
> long thought that names as pairs ( namespace, localname ) would perhaps 
> be an improvement, I'm not suggesting this, but perhaps the ideal fix 
> given a blank sheet of paper should be defined.
> Best,
> Nathan

David Booth, Ph.D.

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Saturday, 26 March 2011 21:54:06 UTC