Re: Why skolemization?

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

Received on Saturday, 26 March 2011 17:08:46 UTC