Re: Representing NULL in RDF

On Jun 5, 2013, at 8:42 AM, Sven R. Kunze wrote:

> Hi Jan,
> 
> some ideas I would like to elaborate to you:
> 
>> I was doing some comparison of relational databases and Linked Data and ran into the problem of representing an equivalent of database NULL in RDF.
> Interesting starting point as relational databases actually do not support your usage scenarios out of the box. A lot of db designers often rethink and re-invent the wheel. So, maybe, it's good to discuss a default way for that issue in RDF.
> 
>> I'm aware of the open world assumption in RDF, but NULL or a missing value can have several interpretations, for example:
> As far as I know, there is no such thing as a NULL value in RDF or in the datatypes of XML Schema.
> rdf:nil is used exclusively for ending rdf:Lists.
> A missing value, as Pat and others already pointed out, carries the meaning of a missing piece of information. However, it might be sensible to introduce new concepts in RDF or related vocabularies to represent the domain-agnostic use-cases below.
> 
> 
> 1)
>> - value not applicable (the attribute does not exist or make sense in the context)
> Maybe, here is a slight misconception of whether the value or the property is not applicable. I for one believe we are talking about the relationship between the current instance (subject :s) and a property :p. (This is at least one <<context>> I could think of, maybe there are more.)
> 
> A One could model this piece of information like this:
> :s rdfs:inapplicableProperty :p.

Hmm. What would the semantics of this be? Can you write any entailment rules for it? I imagine this might be one, for example:

x rdfs:InapplicableProperty p .
x p y .

are unsatisfiable (inconsistent), for any y. Does that capture your intended meaning adequately? Are there any other entailments that would be required?

> (Given that RDFS incorporates inapplicableProperty.)
> 
> B Another way of modelling would be
> :s :p rdfs:inapplicable.

That has the consequence in RDFS that, for example

rdfs:inapplicable rdf:type :A .

when :A is asserted to be an rdfs:range of :p . Would that be acceptable?

> (Given that RDFS incorporates inapplicable)
> 
> I would like to see variant A as the relationship is between the current subject and a schema element (the property) and not between the subject and a non-existent value.
> A schema could even define rdfs:inapplicableProperties for constant-instances in order prevent or detect mis-use.
> 
> 
> 2)
>> - value uknown (it should be there but the source doesn't know it)
> Actually that piece of information could be written down in a RDF Schema graph like this:

It can be written far more simply in RDF just by using a blank node:

:a :p _:x .

Pat Hayes

> 
> #schema
> :A a rdfs:Class.
> :p a rdf:Property; a rdfs:RequiredProperty; rdfs:domain :A.
> 
> #instance
> :x a :A; :p :y. # << :x is carries required property
> :z a :A. # << :z does not carry required property
> 
> Point here is, that instances cannot "decide" whether or not they have to carry properties or not. The fact, that :z should carry a :p property but doesn't consists of two distince pieces of information:
>    - :z should carry :p <<< schema information
>    - :z does not carry :p <<< instance information
> 
> 
> 3)
>> - value doesn't exist (e.g. year of death for a person alive)
> I am not quite sure whether this variant is a distinct one or either falls into 1) or 2).
> Maybe that use case is inappropriate to explain what you really mean by "doesn't exist".
> I tend to say that for such instances of persons they could carry rdfs:inapplicableProperty properties for the properties in question.
> 
> 
> 4)
>> - value is witheld (access not allowed)
> Interesting case, I'd say. I think here we should talk about access granularity. First, I'd like to have a real usage scenario. Second, I might have security consideration: it is really necessary that we tell an untrusted requester whether we don't have that information or we do not want to give it to him? Third, taken that under consideration what could a trustworthy requester do with such information?
> 
> Besides such considerations, I think in this case we should rethink the way we deliver data. It is not really the subject :s which is in a relationship :p of an value that signifies "being-withheld", so:
> :x :p rdfs:noAccess, rdfs:withheld, ...
> doesn't seem appropriate to me.
> 
> It is the requester that influences the delivered data, not the subject:
> @prefix :sec <...> <<< security namespace
> 
> []  a sec:PropertyWithheld;
>       sec:requester <....>;
> #    sec:instance :s;  << optional as generally all subjects with that particular property can be withheld
>       sec:property :p.
> 
> ----------------------------------------------------------------
> 
> What about composite values like in
> :foo :aProp [a :nullableValue; rdf:value "value"] ;
>           :bProp [a :nullableValue; :reason :notAvailable ].
> 
> First of all, I do not really know why we have to merge schema information into instance data.
> Second, there is a second level of graph traversal, which I preferably would like to avoid as it clutters up queries and the triple store.
> Third, most of your given examples are schema design issues (there might be more examples) can be solved without introducing a clumsy composite value.
> Forth, a composite values disturbs the data design when there are "normal" values which can be expressed via "normal" literals, URIs, bnodes. That is, the access queries differ from property to property which should be avoided as it complifies(??) a lot.
> 
> Cheers,
> Sven
> 
> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Sunday, 9 June 2013 19:36:30 UTC