RE: Representing NULL in RDF

[Isabelle L Augenstein]

Precisely, they should have both: projected age and age at death.
On 14 Jun 2013 11:37, "Andy Turner"  wrote:

> > Do dead persons have an age?
>
> That depends. A body of a dead person belonged to a living person. The
> idea of a person can live on. Indeed there are still anniversary
> celebrations of famous people's life events. The work of a person can also
> live on. People are partly defined by their ideas and identity, but they
> are currently inherently linked to their body which is itself made of parts
> that are continually updating.
>
> Toodle Pip!
>
>
>

Re: Representing NULL in RDF

[Gannon Dick]

1. Trivial Use Case:  If you ask my big sister's age, *you* are the dead 
person.  Her motto is "39 'till the end of time".
2. Wonky version (Autoclass (A Bayesian Classifier from NASA) documentation)
"Truncation error will often dominate measurement error.  Here the
classical example is human age: measurable to within a few minutes,
easily computable to within a few days, yet generally reported in years.
The reported value has been truncated to much less than its potential
precision.  Thus the error in that reported value is on the order of
half the least difference of the representation.  Truncation error can
arise from a variety of causes.  Its presence should be suspected
whenever measurements of intrinsically continuous properties are reported
as integers or limited precision floating point numbers."

Hope this helps.
--Gannon




- Original Message -
From: Andy Turner 
To: 'Karl Dubost' ; Juan Sequeda 
Cc: public-lod 
Sent: Friday, June 14, 2013 5:35 AM
Subject: RE: Representing NULL in RDF

> Do dead persons have an age?

That depends. A body of a dead person belonged to a living person. The idea of 
a person can live on. Indeed there are still anniversary celebrations of famous 
people's life events. The work of a person can also live on. People are partly 
defined by their ideas and identity, but they are currently inherently linked 
to their body which is itself made of parts that are continually updating.

Toodle Pip!

Re: Representing NULL in RDF

[Rob Warren]

Given a document date, age is an important feature in disambiguating identity 
since it loosely relates to date of birth. It's also used in many situations 
where a date of birth would create personal privacy issues.

Most properties change over time. The LOD community has a bias for facts that 
are static or "true right now" and we're still working out how to deal with 
historical changes.

Rob
On 2013-06-14, at 7:11 AM, Richard Light wrote:

> Surely it's as pointless to record an age as a property, as it is to stop a 
> clock at the current time, and say "there, that's nailed it".  Current age is 
> the distance between two points in time, one fixed and one not (unless you're 
> talking about "age of a person when some other event, such as their death, 
> occurred").
> 
> Richard
> 
> -- 
> Richard Light

Re: Representing NULL in RDF

[Brian McBride]

On 14/06/2013 11:35, Andy Turner wrote:

Do dead persons have an age?

That depends.
Can depend on what you mean by person and what you mean by age.  If  
denotes me in an enduring sense, i.e. I am the same person I was 
yesterday, then my age is a function of time, I'm older today than I was 
yesterday.


In that sense of person, a dead person can/does have an age - a function 
of time.  I'll leave it to others to choose which ranges of time that 
function has a defined value for and indeed what the range of that 
function is, i.e. whether it includes .


Unless you want to explore issues involving change over time, it is 
simpler to stick to examples like date of birth/death.


Brian

Re: Representing NULL in RDF

[Richard Light]

On 14/06/2013 11:35, Andy Turner wrote:

Do dead persons have an age?

That depends. A body of a dead person belonged to a living person. The idea of 
a person can live on. Indeed there are still anniversary celebrations of famous 
people's life events. The work of a person can also live on. People are partly 
defined by their ideas and identity, but they are currently inherently linked 
to their body which is itself made of parts that are continually updating.


Continually degrading, I find ... :-)

Surely it's as pointless to record an age as a property, as it is to 
stop a clock at the current time, and say "there, that's nailed it".  
Current age is the distance between two points in time, one fixed and 
one not (unless you're talking about "age of a person when some other 
event, such as their death, occurred").


Richard

--
*Richard Light*

RE: Representing NULL in RDF

[Andy Turner]

> Do dead persons have an age?

That depends. A body of a dead person belonged to a living person. The idea of 
a person can live on. Indeed there are still anniversary celebrations of famous 
people's life events. The work of a person can also live on. People are partly 
defined by their ideas and identity, but they are currently inherently linked 
to their body which is itself made of parts that are continually updating.

Toodle Pip!

Re: Representing NULL in RDF

[Karl Dubost]

Juan Sequeda [2013-06-12T15:13]:
> If I have a NULL for the column age, we can all assume that everybody has an 
> age (there exist an age), but I don't know what it is. So it would be "safe" 
> to have   :age _:age

Do dead persons have an age?



-- 
Karl Dubost
http://www.la-grange.net/karl/

Re: Representing NULL in RDF

[Pat Hayes]

Just for the record, I was suggesting the blank node only to represent the 
***case described below***, not as a general replacement for NULL, which seems 
to have many meanings. In the original message this was one of four or five 
possible NULL meanings. 

Pat

On Jun 12, 2013, at 11:08 AM, Tim Berners-Lee wrote:

> 
> On 2013-06 -10, at 19:48, Steve Harris wrote:
> 
>> On 2013-06-09, at 20:36, Pat Hayes  wrote:
>> ...
> ***- 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 .
>> 
>> Yes, a blank node is probably the closest thing to a SQL NULL in RDF.
> 
> 
> Surely a null in  an RDF database conveys no information about the 
> thing, unless you have out of band knowledge. 
> If you have NULL for a cellphonenumber, then that normally means no one 
> stored a cellphone number,
> but it doesn't mean that there is a cellphone whose number is unknown.
> 
> A blank node means "There exists one."   As in "This person has some 
> cellphone number".
> which is very different.
> 
> Nulls should be converted.
> 
> Tim
> 


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

RE: Representing NULL in RDF

[Andy Turner]

Eyup!

This is something that I've thought about quite a lot as a geographer modelling 
the world, society, organisations and people. I have a model that represents 
individuals and which ticks on a daily time step, so Juan's email is back on 
this topic so I thought I'd pipe up again. Some may think that everything can 
be defined with triples, but I think that is only the case if we are modelling 
in context, such as within a single frame of time. So maybe this helps and 
maybe not, at least it is fairly brief:

Do people have an age if they are dead? Probably they don't have an age much 
before they are born.

At best we have an approximate time of birth and time of conception for people.

Those that have died have a time of death. Again this is only known 
approximately, so ranges are important with such things.

To estimate  a person's age at a particular time there can be a calculation.

Then we can express that a person has an age at a particular time. It really 
only makes sense to give an age anchored to a time.

In other words, age is such a continuous variable that I don't think it really 
makes expressing an individuals' age without more context.

But age is also discrete. People commonly talk of age meaning age in years 
(after some event e.g. birth). Indeed anniversaries are important events and 
rules change for people depending on this and depending on other dates that 
pass while someone is aged in a particular age category.

My point is that to deal with age, you need something more than triples unless 
all your data related to a single point in time.

People are more complicated than buildings, but consider the above about age 
when considering a building or something even less well defined like an 
organisation.

I hope if nothing more that this was good food for thought.

Best wishes,

Andy
http://www.geog.leeds.ac.uk/people/a.turner/

From: Juan Sequeda [mailto:juanfeder...@gmail.com]
Sent: 12 June 2013 20:13
To: Tim Berners-Lee
Cc: Steve Harris; Pat Hayes; Sven R. Kunze; public-lod
Subject: Re: Representing NULL in RDF

It depends.

If I have a NULL for the column age, we can all assume that everybody has an 
age (there exist an age), but I don't know what it is. So it would be "safe" to 
have   :age _:age

Juan Sequeda
+1-575-SEQ-UEDA
www.juansequeda.com<http://www.juansequeda.com>

On Wed, Jun 12, 2013 at 11:08 AM, Tim Berners-Lee 
mailto:ti...@w3.org>> wrote:

On 2013-06 -10, at 19:48, Steve Harris wrote:

> On 2013-06-09, at 20:36, Pat Hayes mailto:pha...@ihmc.us>> 
> wrote:
> ...
>>>> - 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 .
>
> Yes, a blank node is probably the closest thing to a SQL NULL in RDF.

Surely a null in  an RDF database conveys no information about the
thing, unless you have out of band knowledge.
If you have NULL for a cellphonenumber, then that normally means no one stored 
a cellphone number,
but it doesn't mean that there is a cellphone whose number is unknown.

A blank node means "There exists one."   As in "This person has some cellphone 
number".
which is very different.

Nulls should be converted.

Tim

Re: Representing NULL in RDF

[Sven R . Kunze]

That is interpreting the RDB NULL in a particular way. Would be nice, if you 
could back your statement with an official writing (only including RDB).


I do not believe, that the RDB NULL explicitly means the absence of 
information. It could mean much more than just that (at least I’ve seen many 
uses). I think the discussion of “Representing NULL in RDF” revealed many of 
those little peculiarities and nuances of not knowing everything:

we make no statement about the existence of that property relation for that 
instance (we just don’tk know)
we know of the existence for that particular subject
we know of the existence for each thing that fulfill a certain condition 
(member of class ...) << that is schema data
we know a reason (e.g. the hypothetical rdfs:inapplicableProperty) for the 
absence of the property
we know a reason (e.g. the hypothetical rdfs:inapplicableProperty) for the 
absence of the property for each thing that fulfill a certain condition (member 
of class ...) <<< that is schema data
we could additionally reveal security data for a data user that is not allowed 
to see certain pieces of data


Hope that’s all so far.


Sven



Von: David Booth
Gesendet: ‎Mittwoch‎, ‎12‎. ‎Juni‎ ‎2013 ‎22‎:‎06
An: Juan Sequeda
Cc: Tim Berners-Lee; Steve Harris; Pat Hayes; Sven R. Kunze; public-lod

Right, but you have used out of band information to know that everyone 
has an age.  No automated process could know that.  null in SQL only 
indicates the absence of information, and that is most naturally 
indicated in RDF by the absence of a triple, just as the RDB-to-RDF 
Direct Mapping produces.  if other domain specific information is known, 
such as the fact that everyone has an age, then that information can be 
represented by additional triples that are implied by the existence of 
the row in the table -- not by the null value in the column.

David

On 06/12/2013 03:13 PM, Juan Sequeda wrote:
> It depends.
>
> If I have a NULL for the column age, we can all assume that everybody
> has an age (there exist an age), but I don't know what it is. So it
> would be "safe" to have   :age _:age
>
> Juan Sequeda
> +1-575-SEQ-UEDA
> www.juansequeda.com <http://www.juansequeda.com>
>
>
> On Wed, Jun 12, 2013 at 11:08 AM, Tim Berners-Lee  <mailto:ti...@w3.org>> wrote:
>
>
> On 2013-06 -10, at 19:48, Steve Harris wrote:
>
>  > On 2013-06-09, at 20:36, Pat Hayes  <mailto:pha...@ihmc.us>> wrote:
>  > ...
>  >>>> - 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 .
>  >
>  > Yes, a blank node is probably the closest thing to a SQL NULL in RDF.
>
>
> Surely a null in  an RDF database conveys no information about the
> thing, unless you have out of band knowledge.
> If you have NULL for a cellphonenumber, then that normally means no
> one stored a cellphone number,
> but it doesn't mean that there is a cellphone whose number is unknown.
>
> A blank node means "There exists one."   As in "This person has some
> cellphone number".
> which is very different.
>
> Nulls should be converted.
>
> Tim
>
>

Re: Representing NULL in RDF

[Juan Sequeda]

David,

You are right and I should have clarified that.

First of all, nulls in rdbms are... hairy.

If you have outside knowledge, which could be given to an automated system,
then generating a triple with a blank node *could* be the right thing to
do. But it all depends on the ... semantics :) Unfortunately, at least in
RDBMSs, a lot of the semantics are in the devs head or in the application
code.

I'm jumping into this thread right in the middle so apologies if I'm
stating something that was already said or obvious.

Just my 2cts.



Juan Sequeda
+1-575-SEQ-UEDA
www.juansequeda.com


On Wed, Jun 12, 2013 at 3:06 PM, David Booth  wrote:

> Right, but you have used out of band information to know that everyone has
> an age.  No automated process could know that.  null in SQL only indicates
> the absence of information, and that is most naturally indicated in RDF by
> the absence of a triple, just as the RDB-to-RDF Direct Mapping produces.
>  if other domain specific information is known, such as the fact that
> everyone has an age, then that information can be represented by additional
> triples that are implied by the existence of the row in the table -- not by
> the null value in the column.
>
> David
>
>
> On 06/12/2013 03:13 PM, Juan Sequeda wrote:
>
>> It depends.
>>
>> If I have a NULL for the column age, we can all assume that everybody
>> has an age (there exist an age), but I don't know what it is. So it
>> would be "safe" to have   :age _:age
>>
>> Juan Sequeda
>> +1-575-SEQ-UEDA
>> www.juansequeda.com 
>>
>>
>>
>> On Wed, Jun 12, 2013 at 11:08 AM, Tim Berners-Lee > > wrote:
>>
>>
>> On 2013-06 -10, at 19:48, Steve Harris wrote:
>>
>>  > On 2013-06-09, at 20:36, Pat Hayes > > wrote:
>>  > ...
>>   - 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 .
>>  >
>>  > Yes, a blank node is probably the closest thing to a SQL NULL in
>> RDF.
>>
>>
>> Surely a null in  an RDF database conveys no information about the
>> thing, unless you have out of band knowledge.
>> If you have NULL for a cellphonenumber, then that normally means no
>> one stored a cellphone number,
>> but it doesn't mean that there is a cellphone whose number is unknown.
>>
>> A blank node means "There exists one."   As in "This person has some
>> cellphone number".
>> which is very different.
>>
>> Nulls should be converted.
>>
>> Tim
>>
>>
>>

Re: Representing NULL in RDF

[David Booth]

Right, but you have used out of band information to know that everyone 
has an age.  No automated process could know that.  null in SQL only 
indicates the absence of information, and that is most naturally 
indicated in RDF by the absence of a triple, just as the RDB-to-RDF 
Direct Mapping produces.  if other domain specific information is known, 
such as the fact that everyone has an age, then that information can be 
represented by additional triples that are implied by the existence of 
the row in the table -- not by the null value in the column.


David

On 06/12/2013 03:13 PM, Juan Sequeda wrote:

It depends.

If I have a NULL for the column age, we can all assume that everybody
has an age (there exist an age), but I don't know what it is. So it
would be "safe" to have   :age _:age

Juan Sequeda
+1-575-SEQ-UEDA
www.juansequeda.com 


On Wed, Jun 12, 2013 at 11:08 AM, Tim Berners-Lee mailto:ti...@w3.org>> wrote:


On 2013-06 -10, at 19:48, Steve Harris wrote:

 > On 2013-06-09, at 20:36, Pat Hayes mailto:pha...@ihmc.us>> wrote:
 > ...
  - 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 .
 >
 > Yes, a blank node is probably the closest thing to a SQL NULL in RDF.


Surely a null in  an RDF database conveys no information about the
thing, unless you have out of band knowledge.
If you have NULL for a cellphonenumber, then that normally means no
one stored a cellphone number,
but it doesn't mean that there is a cellphone whose number is unknown.

A blank node means "There exists one."   As in "This person has some
cellphone number".
which is very different.

Nulls should be converted.

Tim

Re: Representing NULL in RDF

[Juan Sequeda]

It depends.

If I have a NULL for the column age, we can all assume that everybody has
an age (there exist an age), but I don't know what it is. So it would be
"safe" to have   :age _:age

Juan Sequeda
+1-575-SEQ-UEDA
www.juansequeda.com


On Wed, Jun 12, 2013 at 11:08 AM, Tim Berners-Lee  wrote:

>
> On 2013-06 -10, at 19:48, Steve Harris wrote:
>
> > On 2013-06-09, at 20:36, Pat Hayes  wrote:
> > ...
>  - 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 .
> >
> > Yes, a blank node is probably the closest thing to a SQL NULL in RDF.
>
>
> Surely a null in  an RDF database conveys no information about the
> thing, unless you have out of band knowledge.
> If you have NULL for a cellphonenumber, then that normally means no one
> stored a cellphone number,
> but it doesn't mean that there is a cellphone whose number is unknown.
>
> A blank node means "There exists one."   As in "This person has some
> cellphone number".
> which is very different.
>
> Nulls should be converted.
>
> Tim
>

Re: Representing NULL in RDF

[Tim Berners-Lee]

On 2013-06 -10, at 19:48, Steve Harris wrote:

> On 2013-06-09, at 20:36, Pat Hayes  wrote:
> ...
 - 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 .
> 
> Yes, a blank node is probably the closest thing to a SQL NULL in RDF.


Surely a null in  an RDF database conveys no information about the 
thing, unless you have out of band knowledge. 
If you have NULL for a cellphonenumber, then that normally means no one stored 
a cellphone number,
but it doesn't mean that there is a cellphone whose number is unknown.

A blank node means "There exists one."   As in "This person has some cellphone 
number".
which is very different.

Nulls should be converted.

Tim

Re: Representing NULL in RDF

[Sven R. Kunze]

Zitat von Pat Hayes :


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

Re: Representing NULL in RDF

[Pat Hayes]

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

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

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

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

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 su

Re: Representing NULL in RDF

[Sven R . Kunze]

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 a

Re: Representing NULL in RDF

[Juan Sequeda]

I heard somebody saying mapping from RDB to RDF? :)

In the RDB2RDF Direct Mapping [1], we do not generate a triple for null
values.

We also studied the direct mapping in the case that there are null values
in our WWW2012 paper [2]

[1] http://www.w3.org/TR/rdb-direct-mapping/
[2] http://www2012.wwwconference.org/proceedings/proceedings/p649.pdf

Juan Sequeda
+1-575-SEQ-UEDA
www.juansequeda.com


On Tue, Jun 4, 2013 at 5:45 AM, Tim Berners-Lee  wrote:

>
> On 2013-06 -03, at 22:39, Jan Michelfeit wrote:
>
> Hi,
> thank you all for your answers.
>
>
>
> ... One "represents" a null by failing to include the relationship
>
> ... RDF semantics make no assumptions about what the absence of a
> proposition/statement means
>
>
> I agree. The question was actually about *distinguishing* between the
> mentioned cases.
>
>
> Well, then you are not mapping from RDB to RDF.
> As in the database the null didn't tell you which of your case
> it is, of your options
>
> - value not applicable (the attribute does not exist or make sense in the
> context)
> - value uknown (it should be there but the source doesn't know it)
> - value doesn't exist (e.g. year of death for a person alive)
> - value is witheld (access not allowed)
>
>
> You can have out of band, outside the table, information to tell you.
> You can rely on assumptions you can make in given applications.
>
> Both of which you can do with graphs too in *exactly and precisely *
> *the same way.*  You can have implicit or explicit assumptions
> about what the absence of a statement means.
>
> So basically IMHO a null maps exactly to no triple.
>
> Tim
>
>

Re: Representing NULL in RDF

[Sven R. Kunze]

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 distu

Re: Representing NULL in RDF

[Sven R. Kunze]

Zitat von Steve Harris :


On 2013-06-09, at 20:36, Pat Hayes  wrote:
...

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


Yes, a blank node is probably the closest thing to a SQL NULL in RDF.

Though it would be safer/clearer to write:

:a :p [] .


We are not talking about serializations. ;)


To emphasise the (NULL = NULL) → FALSE behaviour, which is key to  
the uses of NULL in SQL.


Excellent point!


However, the convention in RDF is just to omit the property for that  
subject where something is unknown - as others have said.


Jan asked about how to distinguish between his four cases which are  
indeed slightly different to each other.


Omitting a triple has therefore a different quality than telling the  
existence of the property of this very subject. So, there is more  
information (existence) than when omitting the whole triple.

--
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.ku...@informatik.tu-chemnitz.de
WWW: http://vsr.informatik.tu-chemnitz.de/people/kunze
Phone: +49 371 531 33882

Re: Representing NULL in RDF

[Steve Harris]

On 2013-06-09, at 20:36, Pat Hayes  wrote:
...
>>> - 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 .

Yes, a blank node is probably the closest thing to a SQL NULL in RDF.

Though it would be safer/clearer to write:

:a :p [] .

To emphasise the (NULL = NULL) → FALSE behaviour, which is key to the uses of 
NULL in SQL.

However, the convention in RDF is just to omit the property for that subject 
where something is unknown - as others have said.

- Steve

-- 
Steve Harris
Experian
+44 20 3042 4132
Registered in England and Wales 653331 VAT # 887 1335 93
80 Victoria Street, London, SW1E 5JL

Re: Representing NULL in RDF

[Pat Hayes]

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

Re: Representing NULL in RDF

[Hugh Glaser]

When you are trying to work out how to model something, try consuming the RDF 
proposed.
It pretty quickly becomes obvious what are some bad things to do.
Either because you get the "wrong" answers, or because the queries you want to 
do are really hard.
the you can concentrate on the choice from a few things to work out which is 
most "fit for purpose".

Just modelling on its own is pretty much worthless - if you aren't querying the 
resultant data, then the model has little value, since you are enacting a 
write-only process.

Best
Hugh

Re: Representing NULL in RDF

[Sven R. Kunze]

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 <> I could think of, maybe there  
are more.)


A One could model this piece of information like this:
:s rdfs:inapplicableProperty :p.
(Given that RDFS incorporates inapplicableProperty.)

B Another way of modelling would be
:s :p rdfs:inapplicable.
(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:


#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

Re: Representing NULL in RDF

[Pat Hayes]

On Jun 4, 2013, at 5:31 AM, Jan Michelfeit wrote:

> Hi,
> 
>> NULL most often simply represents that the value is not known, in my 
>> experience
> 
> So another conclusion of this discussion can be that unknown is the most 
> sensible default interpretation if the triple is not there and there is no 
> indication of the other cases.
> 
>> I think that you have to ask exactly what is meant and then model it. ... 
>> the purpose of the whole exercise is to construct some RDF that is easy to 
>> query
> 
> My original motivation was actually not modelling such situation, but rather 
> interpreting data from unknown sources.
> 
> An example: Let's have a paper ex:paper. Source A claims "ex:paper 
> ex:reviewedBy ex:Hugh". Source B doesn't have any triple "ex:paper 
> ex:reviewedBy *".
> Now I want to integrate the two sources. Shall the result be "the paper was 
> reviewed by Hugh" or "we are not certain whether the paper's been reviewed 
> because source B says it has not been".

Well, certainly not the second, as B does not say it has not been reviewed. B 
simply makes no assertion about the reviewing. In an open world, it is not 
correct to infer "source says not X" from "source does not say X". If you want 
to be able to say that a paper is not reviewed, then (since RDF does not 
provide you with a built-in "not") you have to find or invent a way to say that 
explicitly. You might for example use OWL-style reasoning and have a class of 
papers reviewed by Hugh (it would be the owl:hasValue ex:Hugh restriction on 
ex:reviewedBy) and then B can say that this paper is not in that class, by 
asserting that its in the complement class. (ex:paper rdf:type 
(owl:complementOf (owl:hasValue ex:reviewedBy ex:Hugh))). But admittedly this 
might be overkill for your example application. 

As to how best to combine data from multiple sources even when they might 
disagree, this is a problem for everyone. But your example would seem to be 
straighforward in the RDF view of things, as your A and B don't actually 
disagree: A just provides some information that B is lacking. One expects such 
things to happen in an open world. 

>> it may be more that the subject of the row is having the property withheld 
>> than the value is a nonVisibleValue.
>> you may well find that there is another field in the DB that actually has 
>> the information already
> 
> Answers in this list have been helpful. The conclusion for me is:
> (1) Don't look just at triples alone, but traverse blank nodes [1], they may 
> bear important information.

Um...blank nodes are parts of triples. I'm not sure what you are intending to 
say here. 

> (2) Dependencies between properties should be considered.
> (3) Conflict resolution should also consider sets of values. In the example 
> above, I would conclude "paper was reviewed"; if ex:reviewedBy was modelled 
> with an RDF collection of reviewers, one empty and one non-empty, I would 
> conclude "we don't know".

Why would you come to that conclusion? 

>> I would always avoid bnodes if it is possible/sensible to do - generating a 
>> URI is not hard, and can be useful in the long run.
> 
> BNodes would be actually useful in my particular use case. There are the only 
> thing which can distinguish an "entity" from a "structured attribute" if we 
> don't know anything about the source.

Again, I don't know what you are talking about, but whatever it is, blank nodes 
don't sound like they have anything to do with it. They don't distinguish one 
kind of thing from another, for sure. 

Pat

> 
> Regards,
> Jan
> 
> [1] http://www.w3.org/Submission/CBD/
> 
> 


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

RE: Representing NULL in RDF

[Andy Turner]

Sorry Hugh, I was agreeing with you... For the first part of my message I was 
thinking about non-triple type RDF/XML where the data may be representing a 
person/entity with various expected attributes. I appreciate that triples can 
be written in RDF/XML too and so the language I used was not very clear.

Andy
http://www.geog.leeds.ac.uk/people/a.turner/
 
-Original Message-
From: Hugh Glaser [mailto:h...@ecs.soton.ac.uk] 
Sent: 04 June 2013 12:00
To: Andy Turner
Cc: Jan Michelfeit; public-lod@w3.org community
Subject: Re: Representing NULL in RDF

Hi Andy,
On 4 Jun 2013, at 11:24, Andy Turner 
 wrote:

> Hi,
> 
> You may not know a persons date/time of birth, but if they were born this can 
> be a property of their linked data. If you know a persons age to a given 
> level of accuracy at a specific time, then you can derive bounds for their 
> date/time of birth and provide a likelihood value for that date/time of 
> birth. Similarly, people once they die have a date/time of death. 
> 
> There is a way of querying linked data to select/filter all living people 
> that may be of a specific age range at a specific time. This can be done both 
> using null values or by implicit null of no property being specified.
> 
> I think for entities which are defined as having specific attributes, then it 
> is better to have null values in the RDF/XML when these are unknown as I 
> think that makes the computation easier.
In that case, is there not the problem I mentioned with peoples' ages?
That is:
So if I have "ex:paper1 ex:reviewedBy ex:Hugh", "ex:paper2 ex:reviewedBy 
ex:NULL", "ex:paper3 ex:reviewedBy ex:NULL"
And I ask the RDF, what other papers were reviewed by the same person, i.e. 
SELECT ?paper WHERE { ex:paper2 ex:reviewedBy ?reviewer . ?paper ex:reviewedBy 
?reviewer }
I get all the papers that have no reviewer in the case ex:paper3

Not really what was expected.
Cheers
> 
> For triple store RDF then I think Hugh is right.
> 
> Of course we have to deal with uncertainty and mess in data about people as 
> we often do not know things accurately for sure! Some times we might discover 
> conflict such that increases our uncertainty about specific attributes.
> 
> Regards,
> 
> Andy
> 
> ____
> From: Hugh Glaser [h...@ecs.soton.ac.uk]
> Sent: 04 June 2013 10:35
> To: Jan Michelfeit
> Cc: 
> Subject: Re: Representing NULL in RDF
> 
> If there is a "*standard or generally accepted*" way of doing things, then, 
> as has been pointed out, it is to ignore it.
> Or rather the norm is that NULL (and "unknown" and anything else like - I'll 
> use NULL for shorthand) that is ignored, and doesn't generate a triple.
> In fact it is really important to do so, as NULL most often simply represents 
> that the value is not known, in my experience.
> Making a triple in such situations is one of the RDF101 basic mistakes, as 
> I'm sure you know, since it causes all sorts of sensible queries to do very 
> strange things.
> For example, if the field is a person's age, then it would mean that a simple 
> query asking for people of the same age as someone of unknown age would give 
> you all the other people whose ages were not known.
> 
> If you are in a generic world where you cannot bring any extra information to 
> the table, then this is all you can do.
> 
> Beyond that, I think that you have to ask exactly what is meant (as you do) 
> and then model it.
> Basically, is there something that is being said by the NULL, and if so, how 
> should that be captured in RDF?
> So your
>> 4. The value is withheld, e.g., when the data consumer is not allowed to 
>> access it.
> 
> should be a "visibility" or "privacy" triple.
> I think this may be what you are doing in (3) below, but I have some concerns 
> about the way you do it there.
> Similarly for others such as
>> 2. The value is unknown, i.e., it should be there but we don't know it.
> which is where you ask the question of whether you want to represent that 
> someone's age is actually missing, with a triple.
> 
> You need to ask what the new property should be attached to.
> It is an important question whether it should be "part of" the value itself.
> So, for a "visibility" triple, it may be more that the subject of the row is 
> having the property withheld than the value is a nonVisibleValue.
> It is the person's foaf:givenName that is not being recorded, not some 
> property of a field from a DB.
> There are patterns in various domains that try to tackle these sorts of 
> problems - in programming languages it is similar to the problem of returning 
> an exception i

Re: Representing NULL in RDF

[Hugh Glaser]

Hi Andy,
On 4 Jun 2013, at 11:24, Andy Turner 
 wrote:

> Hi,
> 
> You may not know a persons date/time of birth, but if they were born this can 
> be a property of their linked data. If you know a persons age to a given 
> level of accuracy at a specific time, then you can derive bounds for their 
> date/time of birth and provide a likelihood value for that date/time of 
> birth. Similarly, people once they die have a date/time of death. 
> 
> There is a way of querying linked data to select/filter all living people 
> that may be of a specific age range at a specific time. This can be done both 
> using null values or by implicit null of no property being specified.
> 
> I think for entities which are defined as having specific attributes, then it 
> is better to have null values in the RDF/XML when these are unknown as I 
> think that makes the computation easier.
In that case, is there not the problem I mentioned with peoples' ages?
That is:
So if I have "ex:paper1 ex:reviewedBy ex:Hugh", "ex:paper2 ex:reviewedBy 
ex:NULL", "ex:paper3 ex:reviewedBy ex:NULL"
And I ask the RDF, what other papers were reviewed by the same person, i.e. 
SELECT ?paper WHERE { ex:paper2 ex:reviewedBy ?reviewer . ?paper ex:reviewedBy 
?reviewer }
I get all the papers that have no reviewer in the case ex:paper3

Not really what was expected.
Cheers
> 
> For triple store RDF then I think Hugh is right.
> 
> Of course we have to deal with uncertainty and mess in data about people as 
> we often do not know things accurately for sure! Some times we might discover 
> conflict such that increases our uncertainty about specific attributes.
> 
> Regards,
> 
> Andy
> 
> ____
> From: Hugh Glaser [h...@ecs.soton.ac.uk]
> Sent: 04 June 2013 10:35
> To: Jan Michelfeit
> Cc: 
> Subject: Re: Representing NULL in RDF
> 
> If there is a "*standard or generally accepted*" way of doing things, then, 
> as has been pointed out, it is to ignore it.
> Or rather the norm is that NULL (and "unknown" and anything else like - I'll 
> use NULL for shorthand) that is ignored, and doesn't generate a triple.
> In fact it is really important to do so, as NULL most often simply represents 
> that the value is not known, in my experience.
> Making a triple in such situations is one of the RDF101 basic mistakes, as 
> I'm sure you know, since it causes all sorts of sensible queries to do very 
> strange things.
> For example, if the field is a person's age, then it would mean that a simple 
> query asking for people of the same age as someone of unknown age would give 
> you all the other people whose ages were not known.
> 
> If you are in a generic world where you cannot bring any extra information to 
> the table, then this is all you can do.
> 
> Beyond that, I think that you have to ask exactly what is meant (as you do) 
> and then model it.
> Basically, is there something that is being said by the NULL, and if so, how 
> should that be captured in RDF?
> So your
>> 4. The value is withheld, e.g., when the data consumer is not allowed to 
>> access it.
> 
> should be a "visibility" or "privacy" triple.
> I think this may be what you are doing in (3) below, but I have some concerns 
> about the way you do it there.
> Similarly for others such as
>> 2. The value is unknown, i.e., it should be there but we don't know it.
> which is where you ask the question of whether you want to represent that 
> someone's age is actually missing, with a triple.
> 
> You need to ask what the new property should be attached to.
> It is an important question whether it should be "part of" the value itself.
> So, for a "visibility" triple, it may be more that the subject of the row is 
> having the property withheld than the value is a nonVisibleValue.
> It is the person's foaf:givenName that is not being recorded, not some 
> property of a field from a DB.
> There are patterns in various domains that try to tackle these sorts of 
> problems - in programming languages it is similar to the problem of returning 
> an exception instead of a value, and things like Union types can get used.
> But remember that you want things to be easy to query for the most basic 
> question, and it is likely that you want to simply have a triple that says
> :foo foaf:givenName "Jan"
> which is what a user expects.
> That then allows
> SELECT ?name WHERE { :foo foaf:givenName ?name }
> In fact, if you have things like your :nullableValue construct, then you 
> can't use predicates such as foaf:givenName at all, since the domain/range 
> constraints are bad (I thin

Re: Representing NULL in RDF

[Hugh Glaser]

Ji Jan,
On 4 Jun 2013, at 11:31, Jan Michelfeit 
 wrote:

> Hi,
> 
>> NULL most often simply represents that the value is not known, in my 
>> experience
> 
> So another conclusion of this discussion can be that unknown is the most 
> sensible default interpretation if the triple is not there and there is no 
> indication of the other cases.
If what you are saying is that a NULL in the DB results in no triple, then yes.
> 
>> I think that you have to ask exactly what is meant and then model it. ... 
>> the purpose of the whole exercise is to construct some RDF that is easy to 
>> query
> 
> My original motivation was actually not modelling such situation, but rather 
> interpreting data from unknown sources.
> 
> An example: Let's have a paper ex:paper. Source A claims "ex:paper 
> ex:reviewedBy ex:Hugh". Source B doesn't have any triple "ex:paper 
> ex:reviewedBy *".
> Now I want to integrate the two sources. Shall the result be "the paper was 
> reviewed by Hugh" or "we are not certain whether the paper's been reviewed 
> because source B says it has not been".
This is not the RDF way.
Source B definitely does not say the paper has not been reviewed - it simply 
remains silent on the matter.
Source A says "the paper was reviewed by Hugh" - if you are including Source A, 
then your conclusion is that "the paper was reviewed by Hugh".
In fact, nothing (simple) that Source B says can contradict that.
And any queries of the two sources together will give you the same answer as 
just Source A.
> 
>> it may be more that the subject of the row is having the property withheld 
>> than the value is a nonVisibleValue.
>> you may well find that there is another field in the DB that actually has 
>> the information already
> 
> Answers in this list have been helpful. The conclusion for me is:
> (1) Don't look just at triples alone, but traverse blank nodes [1], they may 
> bear important information.
I don't quite see this in the context of your original message.
If you are telling the consumers of the RDF you generate that they should do 
this, then fair enough.
By the way, bnodes are also parts of triples, so there is nothing special about 
traversing them.
What you seem to be saying is that you should explore the graph around a 
resource to see if there is any important information, which is of course true.
> (2) Dependencies between properties should be considered.
> (3) Conflict resolution should also consider sets of values. In the example 
> above, I would conclude "paper was reviewed"; if ex:reviewedBy was modelled 
> with an RDF collection of reviewers, one empty and one non-empty, I would 
> conclude "we don't know".
As I say, this is contrary to the RDF way, to put it mildly.
You should conclude that there is at least one reviewer.

I think there is a problem here which is common to the move from DB to RDF.
It is necessary to sometimes step back from the DB and actually ask what the DB 
is trying to represent at a more abstract level - a naive translation will just 
produce poor (that is hard to consume) RDF.
In this case you seem to be trying to infer things (various things at different 
places) from the presence or otherwise of a value in a triple.
RDF just doesn't work like that, especially when combining sources, as you 
describe.
> 
>> I would always avoid bnodes if it is possible/sensible to do - generating a 
>> URI is not hard, and can be useful in the long run.
> 
> BNodes would be actually useful in my particular use case. There are the only 
> thing which can distinguish an "entity" from a "structured attribute" if we 
> don't know anything about the source.
But you can often make up a URI for the bnode.

Good fun!
Best
Huh
> 
> Regards,
> Jan
> 
> [1] http://www.w3.org/Submission/CBD/

Re: Representing NULL in RDF

[Tim Berners-Lee]

On 2013-06 -03, at 22:39, Jan Michelfeit wrote:

> Hi,
> thank you all for your answers.

> 
>> ... One "represents" a null by failing to include the relationship
>> ... RDF semantics make no assumptions about what the absence of a 
>> proposition/statement means
> 
> I agree. The question was actually about *distinguishing* between the 
> mentioned cases.

Well, then you are not mapping from RDB to RDF.
As in the database the null didn't tell you which of your case
it is, of your options

> - value not applicable (the attribute does not exist or make sense in the 
> context)
> - value uknown (it should be there but the source doesn't know it)
> - value doesn't exist (e.g. year of death for a person alive)
> - value is witheld (access not allowed)

You can have out of band, outside the table, information to tell you.
You can rely on assumptions you can make in given applications.

Both of which you can do with graphs too in exactly and precisely 
the same way.  You can have implicit or explicit assumptions
about what the absence of a statement means.

So basically IMHO a null maps exactly to no triple.

Tim

Re: Representing NULL in RDF

[Jan Michelfeit]

Hi,

> NULL most often simply represents that the value is not known, in my 
> experience

So another conclusion of this discussion can be that unknown is the most 
sensible default interpretation if the triple is not there and there is no 
indication of the other cases.

> I think that you have to ask exactly what is meant and then model it. ... the 
> purpose of the whole exercise is to construct some RDF that is easy to query

My original motivation was actually not modelling such situation, but rather 
interpreting data from unknown sources.

An example: Let's have a paper ex:paper. Source A claims "ex:paper 
ex:reviewedBy ex:Hugh". Source B doesn't have any triple "ex:paper 
ex:reviewedBy *".
Now I want to integrate the two sources. Shall the result be "the paper was 
reviewed by Hugh" or "we are not certain whether the paper's been reviewed 
because source B says it has not been".

> it may be more that the subject of the row is having the property withheld 
> than the value is a nonVisibleValue.
>  you may well find that there is another field in the DB that actually has 
> the information already

Answers in this list have been helpful. The conclusion for me is:
(1) Don't look just at triples alone, but traverse blank nodes [1], they may 
bear important information.
(2) Dependencies between properties should be considered.
(3) Conflict resolution should also consider sets of values. In the example 
above, I would conclude "paper was reviewed"; if ex:reviewedBy was modelled 
with an RDF collection of reviewers, one empty and one non-empty, I would 
conclude "we don't know".

> I would always avoid bnodes if it is possible/sensible to do - generating a 
> URI is not hard, and can be useful in the long run.

BNodes would be actually useful in my particular use case. There are the only 
thing which can distinguish an "entity" from a "structured attribute" if we 
don't know anything about the source.

Regards,
Jan

[1] http://www.w3.org/Submission/CBD/

RE: Representing NULL in RDF

[Andy Turner]

Hi,

You may not know a persons date/time of birth, but if they were born this can 
be a property of their linked data. If you know a persons age to a given level 
of accuracy at a specific time, then you can derive bounds for their date/time 
of birth and provide a likelihood value for that date/time of birth. Similarly, 
people once they die have a date/time of death. 

There is a way of querying linked data to select/filter all living people that 
may be of a specific age range at a specific time. This can be done both using 
null values or by implicit null of no property being specified.

I think for entities which are defined as having specific attributes, then it 
is better to have null values in the RDF/XML when these are unknown as I think 
that makes the computation easier.

For triple store RDF then I think Hugh is right.

Of course we have to deal with uncertainty and mess in data about people as we 
often do not know things accurately for sure! Some times we might discover 
conflict such that increases our uncertainty about specific attributes.

Regards,

Andy


From: Hugh Glaser [h...@ecs.soton.ac.uk]
Sent: 04 June 2013 10:35
To: Jan Michelfeit
Cc: 
Subject: Re: Representing NULL in RDF

If there is a "*standard or generally accepted*" way of doing things, then, as 
has been pointed out, it is to ignore it.
Or rather the norm is that NULL (and "unknown" and anything else like - I'll 
use NULL for shorthand) that is ignored, and doesn't generate a triple.
In fact it is really important to do so, as NULL most often simply represents 
that the value is not known, in my experience.
Making a triple in such situations is one of the RDF101 basic mistakes, as I'm 
sure you know, since it causes all sorts of sensible queries to do very strange 
things.
For example, if the field is a person's age, then it would mean that a simple 
query asking for people of the same age as someone of unknown age would give 
you all the other people whose ages were not known.

If you are in a generic world where you cannot bring any extra information to 
the table, then this is all you can do.

Beyond that, I think that you have to ask exactly what is meant (as you do) and 
then model it.
Basically, is there something that is being said by the NULL, and if so, how 
should that be captured in RDF?
So your
> 4. The value is withheld, e.g., when the data consumer is not allowed to 
> access it.

should be a "visibility" or "privacy" triple.
I think this may be what you are doing in (3) below, but I have some concerns 
about the way you do it there.
Similarly for others such as
> 2. The value is unknown, i.e., it should be there but we don't know it.
which is where you ask the question of whether you want to represent that 
someone's age is actually missing, with a triple.

You need to ask what the new property should be attached to.
It is an important question whether it should be "part of" the value itself.
So, for a "visibility" triple, it may be more that the subject of the row is 
having the property withheld than the value is a nonVisibleValue.
It is the person's foaf:givenName that is not being recorded, not some property 
of a field from a DB.
There are patterns in various domains that try to tackle these sorts of 
problems - in programming languages it is similar to the problem of returning 
an exception instead of a value, and things like Union types can get used.
But remember that you want things to be easy to query for the most basic 
question, and it is likely that you want to simply have a triple that says
:foo foaf:givenName "Jan"
which is what a user expects.
That then allows
SELECT ?name WHERE { :foo foaf:givenName ?name }
In fact, if you have things like your :nullableValue construct, then you can't 
use predicates such as foaf:givenName at all, since the domain/range 
constraints are bad (I think).

Of course you may well find that there is another field in the DB that actually 
has the information already, and is being transformed into RDF as well, in 
which case the NULL field can simply be discarded.

I think for these two I would just leave them without a triple:
> 1. The value is not applicable, i.e. property p does not exist or does not 
> make sense in the context.
> 3. The value doesn't exist, i.e. the property doesn't have a value (e.g. year 
> of death for a person alive).

I don't think I would go of into RDFS and OWL specifically to capture things - 
it is likely that the DB is simply modelling things in an unclear way, and the 
challenge of transforming to RDF is to work out what the fuzziness was and 
shine a light on it.
Remember that the purpose of the whole exercise is to construct some RDF that 
is easy to query - or at least I hope that is the purpose!
So not having triples for things that don't hav

Re: Representing NULL in RDF

[Hugh Glaser]

If there is a "*standard or generally accepted*" way of doing things, then, as 
has been pointed out, it is to ignore it.
Or rather the norm is that NULL (and "unknown" and anything else like - I'll 
use NULL for shorthand) that is ignored, and doesn't generate a triple.
In fact it is really important to do so, as NULL most often simply represents 
that the value is not known, in my experience.
Making a triple in such situations is one of the RDF101 basic mistakes, as I'm 
sure you know, since it causes all sorts of sensible queries to do very strange 
things.
For example, if the field is a person's age, then it would mean that a simple 
query asking for people of the same age as someone of unknown age would give 
you all the other people whose ages were not known.

If you are in a generic world where you cannot bring any extra information to 
the table, then this is all you can do.

Beyond that, I think that you have to ask exactly what is meant (as you do) and 
then model it.
Basically, is there something that is being said by the NULL, and if so, how 
should that be captured in RDF?
So your
> 4. The value is withheld, e.g., when the data consumer is not allowed to 
> access it.

should be a "visibility" or "privacy" triple.
I think this may be what you are doing in (3) below, but I have some concerns 
about the way you do it there.
Similarly for others such as
> 2. The value is unknown, i.e., it should be there but we don't know it.
which is where you ask the question of whether you want to represent that 
someone's age is actually missing, with a triple.

You need to ask what the new property should be attached to.
It is an important question whether it should be "part of" the value itself.
So, for a "visibility" triple, it may be more that the subject of the row is 
having the property withheld than the value is a nonVisibleValue.
It is the person's foaf:givenName that is not being recorded, not some property 
of a field from a DB.
There are patterns in various domains that try to tackle these sorts of 
problems - in programming languages it is similar to the problem of returning 
an exception instead of a value, and things like Union types can get used.
But remember that you want things to be easy to query for the most basic 
question, and it is likely that you want to simply have a triple that says
:foo foaf:givenName "Jan"
which is what a user expects.
That then allows
SELECT ?name WHERE { :foo foaf:givenName ?name }
In fact, if you have things like your :nullableValue construct, then you can't 
use predicates such as foaf:givenName at all, since the domain/range 
constraints are bad (I think).

Of course you may well find that there is another field in the DB that actually 
has the information already, and is being transformed into RDF as well, in 
which case the NULL field can simply be discarded.

I think for these two I would just leave them without a triple:
> 1. The value is not applicable, i.e. property p does not exist or does not 
> make sense in the context.
> 3. The value doesn't exist, i.e. the property doesn't have a value (e.g. year 
> of death for a person alive).

I don't think I would go of into RDFS and OWL specifically to capture things - 
it is likely that the DB is simply modelling things in an unclear way, and the 
challenge of transforming to RDF is to work out what the fuzziness was and 
shine a light on it.
Remember that the purpose of the whole exercise is to construct some RDF that 
is easy to query - or at least I hope that is the purpose!
So not having triples for things that don't have values is good.
And having triples that give more information about things is also good, as 
they are very easy to query.
In fact, using RDFS and OWL for what is likely to be simple stuff from a DB is 
only likely to provide checking at assertion, and not add anything easy to 
querying - and since you are transforming from a DB, it is likely that the data 
you are transforming is well-formed.

Finally, I know this generates controversy, but I would always avoid bnodes if 
it is possible/sensible to do - generating a URI is not hard, and can be useful 
in the long run. In your example, you could just as easily say "Use a node to 
give more details about the questioned value."

Sorry, I've gone on a bit, but I just went with the flow!

Best
Hugh

On 3 Jun 2013, at 22:39, Jan Michelfeit 
 wrote:

> Hi,
> thank you all for your answers.
> 
>> ... One "represents" a null by failing to include the relationship
>> ... RDF semantics make no assumptions about what the absence of a 
>> proposition/statement means
> 
> I agree. The question was actually about *distinguishing* between the 
> mentioned cases.
> 
>> From your suggestions and a quite comprehensive answer at SO [1], I see 
>> these solutions:
> 
> (1) Use ontology to specify proper constraints. This may be cardinality of 
> the questioned property or, as suggested by Phillip, assertion "that anything 
> with a year of death is necessari

Re: Representing NULL in RDF

[Jan Michelfeit]

Hi,
thank you all for your answers.

> ... One "represents" a null by failing to include the relationship
> ... RDF semantics make no assumptions about what the absence of a 
> proposition/statement means

I agree. The question was actually about *distinguishing* between the mentioned 
cases.

>From your suggestions and a quite comprehensive answer at SO [1], I see these 
>solutions:

(1) Use ontology to specify proper constraints. This may be cardinality of the 
questioned property or, as suggested by Phillip, assertion "that anything with 
a year of death is necessarily a dead person".

(2) Use an RDF container and possibly rdf:nil (thanks to Barry and Robert for 
his example) .

(3) Use a blank node to give more details about the questioned value. Examle 
[2]:
   :foo :aProp [a :nullableValue; rdf:value "value"] ;
:bProp [a :nullableValue; :reason :notAvailable ]

Regards,
Jan

[1] http://stackoverflow.com/a/16889273/2032064
[2] http://stackoverflow.com/a/16898786/2032064

Re: Representing NULL in RDF

[Barry Norton]

On 03/06/13 15:31, Robert Sanderson wrote:


Our solution was to use rdf:nil, but we would be happy to change that 
if there is a more appropriate approach.




That was my suggested solution last time this came up on list. It does 
make rdf:nil a member of the property's range though, which is... odd.


Barry

Re: Representing NULL in RDF

[Barry Norton]

Apologies, I'm reading out of order - David and Pat seem to have 
introduced already what OWA mandates here (in absence of a relationship).


Let me just reiterate, then, what I'm trying to say - with an RDBMS hat 
on, I agree that sometimes a null is a 'positive' null, and I too would 
like sometimes to say that in RDF.


(With OWL could I not define a subclass of the relationship domain with 
a zero cardinality constraint on the property and make the 
'positively-null' an instance of that subclass? Apologies if this too 
has been covered...)


Barry



On 03/06/13 21:58, Barry Norton wrote:

On 03/06/13 16:52, Phillip Lord wrote:


Value unknown is easy. Just don't say anything.

Value not applicable and doesn't exist, given your examples, seem the
same to me.


I don't agree. Under the Open World assumption anything that can later 
be learned should not affect consistency. A positive null ("there is 
no such") should lead to a contradiction is someone later asserts such 
a value/relationship (which doesn't happen with a simple unpopulated 
relationship from the subject).


In RDF (which has been my answer before - feel free to contradict me, 
I'm not an authority, it's just that I've made the proposal before) 
this seems possible only with Collections. What I mean by this is that 
with a list-ranged relationship I can specify a value of 'there is no 
such' (rdf:nil) and someone trying to populate the list later would 
have to revert that fact to provide such a value. Without a list 
expected, this does not seem possible (again, to me).


Barry

Re: Representing NULL in RDF

[Barry Norton]

On 03/06/13 16:52, Phillip Lord wrote:


Value unknown is easy. Just don't say anything.

Value not applicable and doesn't exist, given your examples, seem the
same to me.


I don't agree. Under the Open World assumption anything that can later 
be learned should not affect consistency. A positive null ("there is no 
such") should lead to a contradiction is someone later asserts such a 
value/relationship (which doesn't happen with a simple unpopulated 
relationship from the subject).


In RDF (which has been my answer before - feel free to contradict me, 
I'm not an authority, it's just that I've made the proposal before) this 
seems possible only with Collections. What I mean by this is that with a 
list-ranged relationship I can specify a value of 'there is no such' 
(rdf:nil) and someone trying to populate the list later would have to 
revert that fact to provide such a value. Without a list expected, this 
does not seem possible (again, to me).


Barry

Re: Representing NULL in RDF

[Pat Hayes]

On Jun 3, 2013, at 10:28 AM, Panzer,Michael wrote:

> Hi David,
> 
> I don't believe this is quite right, as RDF semantics make no assumptions 
> about what the absence of a proposition/statement means.

Well, actually it does. Absence of a proposition means exactly that its 
truthvalue is undetermined, unless of course it is entailed by something that 
is present. This is true for RDF and all RDF semantic extensions, including OWL.

> Only more constrained/expressive languages like OWL define this clearly, and 
> in fact, in OWL it is quite the opposite.
> 
> The Open World Assumption used in OWL

and in RDF

> holds that the absence of a statement cannot be construed to mean the 
> statement is false. The truth-value is independent of its presence/absence. 
> (How "false" maps to "null" is another questions.)

All true. Although I don't think it is ever correct to map "null" to "false".

Pat

> 
> Cheers
> Michael
> 
> -Original Message-
> From: David Wood [mailto:da...@3roundstones.com] 
> Sent: Montag, 3. Juni 2013 09:44
> To: Jan Michelfeit
> Cc: public-lod@w3.org
> Subject: Re: Representing NULL in RDF
> 
> Hi Jan,
> 
> That's because nulls are generally not represented in Linked Data by design.  
> One "represents" a null by failing to include the relationship.  
> 
> Regards,
> Dave
> 
> 
> On Jun 3, 2013, at 4:38, Jan Michelfeit  wrote:
> 
>> Hi,
>> 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.
>> 
>> I was surprised I haven't found any material or discussion on this topic 
>> (found only [1]) - is there some?. I believe it would be beneficial if this 
>> question was answered somewhere for future reference. I started a question 
>> on Stack Overflow [2] where I think it will be easier to discover and so 
>> that this list won't get polluted.
>> 
>> I'm aware of the open world assumption in RDF, but NULL or a missing value 
>> can have several interpretations, for example:
>> 
>> - value not applicable (the attribute does not exist or make sense in the 
>> context)
>> - value uknown (it should be there but the source doesn't know it)
>> - value doesn't exist (e.g. year of death for a person alive)
>> - value is witheld (access not allowed)
>> 
>> I would like to known whether there is some *standard or generally accepted* 
>> way of distinguishing these cases. If you have an answer, please put it on 
>> [2], is possible.
>> 
>> Thanks in advance,
>> Jan Michelfeit
>> 
>> [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Nov/0167.html
>> [2] http://stackoverflow.com/q/16873174/2032064
>> 
>> 
> 
> 
> 
> 
> 


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

Re: Representing NULL in RDF

[David Wood]

Hi Michael,

I agree in regard to OWL, of course.  I took Jan's question to relate to a 
generic Linked Data context since this is public-lod not (e.g.) public-owl-dev.

Regards,
Dave


On Jun 3, 2013, at 11:28, "Panzer,Michael"  wrote:

> Hi David,
> 
> I don't believe this is quite right, as RDF semantics make no assumptions 
> about what the absence of a proposition/statement means. Only more 
> constrained/expressive languages like OWL define this clearly, and in fact, 
> in OWL it is quite the opposite.
> 
> The Open World Assumption used in OWL holds that the absence of a statement 
> cannot be construed to mean the statement is false. The truth-value is 
> independent of its presence/absence. (How "false" maps to "null" is another 
> questions.)
> 
> Cheers
> Michael
> 
> -Original Message-
> From: David Wood [mailto:da...@3roundstones.com] 
> Sent: Montag, 3. Juni 2013 09:44
> To: Jan Michelfeit
> Cc: public-lod@w3.org
> Subject: Re: Representing NULL in RDF
> 
> Hi Jan,
> 
> That's because nulls are generally not represented in Linked Data by design.  
> One "represents" a null by failing to include the relationship.  
> 
> Regards,
> Dave
> 
> 
> On Jun 3, 2013, at 4:38, Jan Michelfeit  wrote:
> 
>> Hi,
>> 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.
>> 
>> I was surprised I haven't found any material or discussion on this topic 
>> (found only [1]) - is there some?. I believe it would be beneficial if this 
>> question was answered somewhere for future reference. I started a question 
>> on Stack Overflow [2] where I think it will be easier to discover and so 
>> that this list won't get polluted.
>> 
>> I'm aware of the open world assumption in RDF, but NULL or a missing value 
>> can have several interpretations, for example:
>> 
>> - value not applicable (the attribute does not exist or make sense in the 
>> context)
>> - value uknown (it should be there but the source doesn't know it)
>> - value doesn't exist (e.g. year of death for a person alive)
>> - value is witheld (access not allowed)
>> 
>> I would like to known whether there is some *standard or generally accepted* 
>> way of distinguishing these cases. If you have an answer, please put it on 
>> [2], is possible.
>> 
>> Thanks in advance,
>> Jan Michelfeit
>> 
>> [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Nov/0167.html
>> [2] http://stackoverflow.com/q/16873174/2032064
>> 
>> 
> 
> 
> 

Re: Representing NULL in RDF

[Phillip Lord]

Jan Michelfeit  writes:
> 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.
>
> I was surprised I haven't found any material or discussion on this topic
> (found only [1]) - is there some?. I believe it would be beneficial if this
> question was answered somewhere for future reference. I started a question on
> Stack Overflow [2] where I think it will be easier to discover and so that
> this list won't get polluted.
>
> I'm aware of the open world assumption in RDF, but NULL or a missing value can
> have several interpretations, for example:
>
> - value not applicable (the attribute does not exist or make sense in the 
> context)
> - value uknown (it should be there but the source doesn't know it)
> - value doesn't exist (e.g. year of death for a person alive)
> - value is witheld (access not allowed)
>
> I would like to known whether there is some *standard or generally accepted*
> way of distinguishing these cases. If you have an answer, please put it on
> [2], is possible.

It's a little unclear what you could do with this. 

Say, for example, you assert that a value is withheld. Then I assert the
value. With a database, this cannot happen; either a value if null or it
is not.

Value unknown is easy. Just don't say anything. 

Value not applicable and doesn't exist, given your examples, seem the
same to me. And depends on what bit of RDF you are using. You can, for
example, assert that anything with a year of death is necessarily a dead
person. Asserting a death date for a life person will result in
contradictory information that you have to deal with in some way.

Phil

RE: Representing NULL in RDF

[Panzer,Michael]

Hi David,

I don't believe this is quite right, as RDF semantics make no assumptions about 
what the absence of a proposition/statement means. Only more 
constrained/expressive languages like OWL define this clearly, and in fact, in 
OWL it is quite the opposite.

The Open World Assumption used in OWL holds that the absence of a statement 
cannot be construed to mean the statement is false. The truth-value is 
independent of its presence/absence. (How "false" maps to "null" is another 
questions.)

Cheers
Michael

-Original Message-
From: David Wood [mailto:da...@3roundstones.com] 
Sent: Montag, 3. Juni 2013 09:44
To: Jan Michelfeit
Cc: public-lod@w3.org
Subject: Re: Representing NULL in RDF

Hi Jan,

That's because nulls are generally not represented in Linked Data by design.  
One "represents" a null by failing to include the relationship.  

Regards,
Dave


On Jun 3, 2013, at 4:38, Jan Michelfeit  wrote:

> Hi,
> 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.
> 
> I was surprised I haven't found any material or discussion on this topic 
> (found only [1]) - is there some?. I believe it would be beneficial if this 
> question was answered somewhere for future reference. I started a question on 
> Stack Overflow [2] where I think it will be easier to discover and so that 
> this list won't get polluted.
> 
> I'm aware of the open world assumption in RDF, but NULL or a missing value 
> can have several interpretations, for example:
> 
> - value not applicable (the attribute does not exist or make sense in the 
> context)
> - value uknown (it should be there but the source doesn't know it)
> - value doesn't exist (e.g. year of death for a person alive)
> - value is witheld (access not allowed)
> 
> I would like to known whether there is some *standard or generally accepted* 
> way of distinguishing these cases. If you have an answer, please put it on 
> [2], is possible.
> 
> Thanks in advance,
> Jan Michelfeit
> 
> [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Nov/0167.html
> [2] http://stackoverflow.com/q/16873174/2032064
> 
> 

Re: Representing NULL in RDF

[Robert Sanderson]

Hi David, Jan,

This came up in a recent modelling discussion around Open Annotation[1] and
its use in Shared Canvas[2].

Open Annotation has a Choice resource (think rdf:Alt) where, for example,
the body of the annotation could be an HTML document or the equivalent text
in PDF from a different site.  One use case for Shared Canvas is where the
body represents the choice where either an image should be displayed, or
the situation that nothing should be displayed.  Here we need an explicit
'null' as the lack of a predicate both doesn't follow the data model (which
requires at least two items in the choice) and isn't clear, given the open
world assumption, that null is possible.

Our solution was to use rdf:nil, but we would be happy to change that if
there is a more appropriate approach.

Many thanks,

Rob Sanderson

1. http://openannotation.org/spec/core/multiplicity.html#Choice
2. http://www.shared-canvas.org/datamodel/iiif/metadata-api.html#AdvChoice





On Mon, Jun 3, 2013 at 7:43 AM, David Wood  wrote:

> Hi Jan,
>
> That's because nulls are generally not represented in Linked Data by
> design.  One "represents" a null by failing to include the relationship.
>
> Regards,
> Dave
>
>
> On Jun 3, 2013, at 4:38, Jan Michelfeit  wrote:
>
> > Hi,
> > 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.
> >
> > I was surprised I haven't found any material or discussion on this topic
> (found only [1]) - is there some?. I believe it would be beneficial if this
> question was answered somewhere for future reference. I started a question
> on Stack Overflow [2] where I think it will be easier to discover and so
> that this list won't get polluted.
> >
> > I'm aware of the open world assumption in RDF, but NULL or a missing
> value can have several interpretations, for example:
> >
> > - value not applicable (the attribute does not exist or make sense in
> the context)
> > - value uknown (it should be there but the source doesn't know it)
> > - value doesn't exist (e.g. year of death for a person alive)
> > - value is witheld (access not allowed)
> >
> > I would like to known whether there is some *standard or generally
> accepted* way of distinguishing these cases. If you have an answer, please
> put it on [2], is possible.
> >
> > Thanks in advance,
> > Jan Michelfeit
> >
> > [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Nov/0167.html
> > [2] http://stackoverflow.com/q/16873174/2032064
> >
> >
>
>

Re: Representing NULL in RDF

[David Wood]

Hi Jan,

That's because nulls are generally not represented in Linked Data by design.  
One "represents" a null by failing to include the relationship.  

Regards,
Dave


On Jun 3, 2013, at 4:38, Jan Michelfeit  wrote:

> Hi,
> 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.
> 
> I was surprised I haven't found any material or discussion on this topic 
> (found only [1]) - is there some?. I believe it would be beneficial if this 
> question was answered somewhere for future reference. I started a question on 
> Stack Overflow [2] where I think it will be easier to discover and so that 
> this list won't get polluted.
> 
> I'm aware of the open world assumption in RDF, but NULL or a missing value 
> can have several interpretations, for example:
> 
> - value not applicable (the attribute does not exist or make sense in the 
> context)
> - value uknown (it should be there but the source doesn't know it)
> - value doesn't exist (e.g. year of death for a person alive)
> - value is witheld (access not allowed)
> 
> I would like to known whether there is some *standard or generally accepted* 
> way of distinguishing these cases. If you have an answer, please put it on 
> [2], is possible.
> 
> Thanks in advance,
> Jan Michelfeit
> 
> [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Nov/0167.html
> [2] http://stackoverflow.com/q/16873174/2032064
> 
> 

Representing NULL in RDF

[Jan Michelfeit]

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

I was surprised I haven't found any material or discussion on this topic (found 
only [1]) - is there some?. I believe it would be beneficial if this question 
was answered somewhere for future reference. I started a question on Stack 
Overflow [2] where I think it will be easier to discover and so that this list 
won't get polluted.

I'm aware of the open world assumption in RDF, but NULL or a missing value can 
have several interpretations, for example:

- value not applicable (the attribute does not exist or make sense in the 
context)
- value uknown (it should be there but the source doesn't know it)
- value doesn't exist (e.g. year of death for a person alive)
- value is witheld (access not allowed)

I would like to known whether there is some *standard or generally accepted* 
way of distinguishing these cases. If you have an answer, please put it on [2], 
is possible.

Thanks in advance,
Jan Michelfeit

[1] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Nov/0167.html
[2] http://stackoverflow.com/q/16873174/2032064