Re: Representing NULL in RDF

>> 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?

Good point. To be honest, I do not know.

Especially, in this case, I could imagine several alternatives leading  
to several different variances of rdfs:inapplicableProperty.
first)
as you have said

second)
no entailment rules at all; just additional data with the following meanings:

a)
s rdfs:inapplicableProperty p.
the data consumer should not expect p so be there in conjunction with  
s at anytime (soon)

b)
s rdfs:inapplicableProperty p.
s p y.
there might have been a time where the graph carried only a); but the  
data provider forget to remove the a) triple

c)
s p y.
as usual



>
>> (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?

Hmm, not sure either. That might be a reason why I would prefer the  
former variant.


>> (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 .

Very interesting and very simple!


However, I am not quite sure, whether or not it has the same semantics.
The schema part might not be able to carry the blank node for each  
possible future instance.

I could even imagine an entailment rule like this:
{ p rdf:type rdfs:RequiredProperty; rdfs:domain A. x rdf:type A } => {  
x p [] }
but the other way round might not sensible, I think.


Cheers,
Sven


>
> 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


-- 
Sven R. Kunze
Chemnitz University of Technology
Department of Computer Science
Distributed and Self-organizing Systems Group
Straße der Nationen 62
D-09107 Chemnitz
Germany
E-Mail: sven.kunze@informatik.tu-chemnitz.de
WWW: http://vsr.informatik.tu-chemnitz.de/people/kunze
Phone: +49 371 531 33882

Received on Monday, 10 June 2013 19:16:08 UTC