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
