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

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

If the information in the graph makes the blank node complete, like in your
example, then yes of course use the type.

Anthony

On Tue, Dec 4, 2018 at 2:44 PM Henry Story <henry.story@bblfish.net> wrote:

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