Re: Representing NULL in RDF

Yes, from the wording, I do agree with you.

However, as the entailment rule says, your conclusion is correct, but the other way round might not. That you know, that there is something for that particular instance, does not imply the necessity for each instance of that rdf:type.

That is, when you know x bears a p relation (but nothing more) you cannot infer that each instance of that type of x bears it.


Another point, which came to my mind lately, it the challenge of updating that particular blank node. It’d required one step more to check whether there is such blank node and then removing it, when it is to be replaced by a named entity. And that only the first time. This might be a rather complex code.


Btw: one idea of getting rid of the rdfs:RequiredProperty class could be including that rule into your schema definition (of course for each (A, p) that it applies to):


{ ?x rdf:type A } => { ?x p [] }


I am not sure what inferring engines actually do when it comes to inferring blank nodes with no further data within. So, when a particular x already have a p relation, maybe that engine dismiss the inferred blank node p relation.


Nevertheless, the primary problem with the blank node solution is the blank node itself and the missing way of pulling schema data out of it; unless you can use something like N3.


Sven


 


Von: Pat Hayes
Gesendet: ‎Dienstag‎, ‎11‎. ‎Juni‎ ‎2013 ‎00‎:‎00
An: Sven R. Kunze

 

On Jun 10, 2013, at 2:15 PM, Sven R. Kunze wrote:

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

Well, the RDF semantics of this is that something exists that :a bears the :p relation to, but you don't (yet) know what it is. Isn't that what you said, above? 

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

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