Re: Representing NULL in RDF

Zitat von Pat Hayes <phayes@ihmc.us>:

> On Jun 11, 2013, at 2:03 PM, Sven R.Kunze wrote:
>
>> 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.
>
> I,m not sure what you mean by 'that type of x', but indeed, you  
> can't infer anything about something else of a given type just from  
> a single fact about one entity.

And that could be problem depending on what a data designer wants to  
achieve/express.


>>
>> 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.
>
> You don't need to remove it. It is still true (though now redundant)  
> when you have the named entity.

Yes, true.


>> And that only the first time. This might be a rather complex code.
>
> Its pretty simple in practice (though its theoretical complxity is  
> hard, the hard cases never arise in practice.) The operation is  
> called 'leaning' (in the sense of "making lean", ie removing  
> redundancies)

Yes, I read about lean graphs in the spec (lean graphs result from  
leaning?). Do you know which tools can do that?


>>
>> 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.
>
> Yes, it would be redundant in that case. Some engines simply leave  
> it alone, others check for redundancies and remove them.

Good to know. Some examples?


>>
>> 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
>
> ? Im not sure what you mean by pulling schema data. You can't pull  
> data from an IRI either (can you?)

Hmmm, I maybe meant separating the schema-related data and the  
instance-related data in such way that the schema-related data can  
express the given use-case of representing required property relations.

>
> Pat
>
>> ; 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
>
> ------------------------------------------------------------
> 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 Tuesday, 11 June 2013 22:39:06 UTC