Functions Re: Blank Nodes Re: Toward easier RDF: a proposal

> On 4 Dec 2018, at 00:15, Anthony Moretti <anthony.moretti@gmail.com> wrote:
> 
> Henry you mentioned keys earlier, I should be clearer and say that by incomplete I mean in terms of key attributes for equality checking. For a blank node of type Person it's not likely the attribute "ancestor" would be a key, that information could be missing, it's more likely something like nationality and social security number for example would be relied upon.

SSN do form identifying keys. In OWL the way to model that is with an inverse 
functional relation such as 

     us:ssn a owl:InverseFunctionalProperty.

and then it can be used as so

<JSmith#> us:ssn "70883955";
     foaf:name "John Smith" .

this is called inverse functional because it identifies an object
the way a function does. So in functional terms one can think of it
as a function such as 

     us:ssn( "70883955") = <JSmith#> 

The nice thing is that because RDF does not require relations to be present
this allows one to use SSN when they are available, but use other identifiers
for people who never had such numbers, such as the ancestors of John Smith.

So if we have family:father and family:mother relating a person to his or her father,
or mother  then we can identify John Smith's father precisely using John as the key,
since those two relations are owl:FunctionalProperties.

   <JSmith#> us:ssn "70883955";
         family:father [ a Pirate ] .

John may just not know much about his father.  The further we go back in someone's
ancestry tree the less one knows, and sometimes a generation is altogether blank -
the father may have left before a child's birth.

If social security numbers are keys then so could a URI with fragment identifier 
be, thoughin that case they are called identifiers. Each state in the US could give 
people born there a URI, perhaps John Smith would get a WebID there such 
as <https://people.gov.ca/1993/JSmith#> and over time these would end up 
replacing SSNs. 

The flexibility of RDF here is quite clearly advantageous. There are many ways
of identifying people. Databases that require strict schemas don't extend far in time
or geographically, and tend to be very inhuman to work with. (Not even considering
the catastrophe that followed from US companies treating SSN as secrets, leading
to all kinds of identity theft scams)

> It's definitely useful to work with partial information, but I'd type it as such. A blank node with a numerator property but not a denominator property I would allow to exist but I wouldn't type it as a Fraction.

Above we saw how we could have a well defined blank node, namely the father of John.

In high school algebra we also have equations such as 

   28/x = 4

that is true just when x = 7

28/x is actually a function 𝜆x. 28/x : ℝ-{0} → ℝ 
which is a curve.

It does raise an interesting question as how one should model functions in RDF.
In the cwm repository ( https://www.w3.org/2000/10/swap/doc/ (a lot of those
pages no longer seem accessible !) I saw some code a while back to model the 
addition function that could interpret a relation from a list (of numbers) to 
their addition that looked like this

(3 7 2) math:product _:x .

cwm would be able to work out that _:x = 42.

There seems to indeed be a math:quotient relation there. Does that then
mean that (28 _:z) math:quotient _:l is a one place function?

I don't know if any more work has been done in that direction.

> Just FYI, in Swift there is what you describe, they're called "optionals". There can be a value there of a specific type, or nothing, and yes you do end up with lots of if statements but they're useful.

In Category theory Option is a functor Opt(X) = 1+X
that is the disjoint union of a one element set and the
type X. One can map any function that works on X to Opt(X)
So for Opt(ℕ) = 1+ℕ one can map the function 

   dec: ℕ → String
 
and so get the function Opt(ℕ)(dec):  Opt(ℕ) → Opt(String)
which takes 1 to 1 and any number to its decimal string representation.
As it happens to also be a monad one can turn any N into an Opt,
one can flatten nested Opt(Opt(ℕ)) → Opt(ℕ).

Scala and Haskell then have syntactic sugar to make it easy to write
code that does not need if then else statements, when chaining
functions some of which may lead to 1. This is also good for
modeling partial functions. Any partial function say 

𝜆x. 28/x : ℝ → ℝ

can be transformed into a full function from  ℝ → Opt(ℝ)

But the function father: Person → Person is not really a
partial function, so using optionals in that case seems
misguided.

> 
> Anthony
> 
> On Mon, Dec 3, 2018 at 2:33 PM Henry Story <henry.story@bblfish.net> wrote:
> 
> 
> > On 3 Dec 2018, at 23:10, Anthony Moretti <anthony.moretti@gmail.com> wrote:
> > 
> > Cheers for agreeing William. On the topic of incomplete blank nodes Henry I'd give them another type, the partial address example you give I'd give the type AddressComponent, or something to that effect. I could be wrong, but it's not a valid Address if it's a blank node and no other information in the graph completes it.
> 
> So saying that you know a Person without specifying all their family tree all the way to
> Adam and Eve would be incomplete information then! 8‑0
> 
> A database can get corrupted and information go missing. Knowing that there was a relation
> from a to b to c without knowing b but knowing that b lived at a certain street, might
> allow you to find the missing information.
> 
> This is exactly the role existential quantifiers play. They allow us to make a statement
> without specifying the object precisely, but require us then to be committed to accepting
> that the graph will be true when the blank node is replaced at one point by the correct
> name.
> 
> In a way you can get this in OO programming by allowing every object's value to be null,
> but then you end up with a lot of if then statements, unless you have some monadic null.
> In a way I find RDF here a lot more satisfactory as it takes incomplete information into
> account.
> 
> Henry
> > 
> > Anthony
> > 
> > On Mon, Dec 3, 2018 at 1:56 PM William Waites <wwaites@tardis.ed.ac.uk> wrote:
> > > standards like schema:PostalAddress should possibly define relevant
> > > operations like equality checking too.
> > 
> > Exactly.
> > 
> > 
>

Received on Tuesday, 4 December 2018 22:44:40 UTC