Re: Representing NULL in RDF

Hi,

> NULL most often simply represents that the value is not known, in my experience

So another conclusion of this discussion can be that unknown is the most sensible default interpretation if the triple is not there and there is no indication of the other cases.

> I think that you have to ask exactly what is meant and then model it. ... the purpose of the whole exercise is to construct some RDF that is easy to query

My original motivation was actually not modelling such situation, but rather interpreting data from unknown sources.

An example: Let's have a paper ex:paper. Source A claims "ex:paper ex:reviewedBy ex:Hugh". Source B doesn't have any triple "ex:paper ex:reviewedBy *".
Now I want to integrate the two sources. Shall the result be "the paper was reviewed by Hugh" or "we are not certain whether the paper's been reviewed because source B says it has not been".

> it may be more that the subject of the row is having the property withheld than the value is a nonVisibleValue.
>  you may well find that there is another field in the DB that actually has the information already

Answers in this list have been helpful. The conclusion for me is:
(1) Don't look just at triples alone, but traverse blank nodes [1], they may bear important information.
(2) Dependencies between properties should be considered.
(3) Conflict resolution should also consider sets of values. In the example above, I would conclude "paper was reviewed"; if ex:reviewedBy was modelled with an RDF collection of reviewers, one empty and one non-empty, I would conclude "we don't know".

> I would always avoid bnodes if it is possible/sensible to do - generating a URI is not hard, and can be useful in the long run.

BNodes would be actually useful in my particular use case. There are the only thing which can distinguish an "entity" from a "structured attribute" if we don't know anything about the source.

Regards,
Jan

[1] http://www.w3.org/Submission/CBD/

Received on Tuesday, 4 June 2013 10:32:30 UTC