Re: URI Collapsing: was (RDF graph merging: How useful is it really? (was Re: Blank Nodes Re: Toward easier RDF: a proposal))

Don't know if my input is helpful here, but this is addressed in a very
comprehensive way in Swift using this protocol hierarchy:

    Equatable (==, !=)
        Comparable (>, <, >=, <=)
        Hashable

Hashable inherits from Equatable, so any type you want to hash must first
satisfy Equatable. If your definition of equivalence is structural
equivalence then you can do this independent of type, but if your
definition of equivalence is based on more then it needs to be defined per
type.

For example:

    var a = {
        type: Fraction,
        numerator: 1,
        denominator: 2
    }

    var b = {
        type: Fraction,
        numerator: 2,
        denominator: 4
    }

These variables aren't structurally equivalent, but with knowledge of
fractions you'd say they were equal and so should arguably produce the same
hash.

Another example of this:

    var c = {
        type: Float,
        value: 0.0
    }

    var d = {
        type: Float,
        value: -0.0
    }

For a common approach to addresses maybe a group like Schema org could
publish *==()* and *hash()* functions on their
https://schema.org/PostalAddress page, possibly open sourced. In the
interim they could nominate an existing service like
https://smartystreets.com/, which is an address validation API I've just
discovered, there seem to be several. At a later stage they could publish a
fuzzy matching function there too.

Anthony

Links:
https://developer.apple.com/documentation/swift/equatable
https://developer.apple.com/documentation/swift/comparable
https://developer.apple.com/documentation/swift/hashable

On Sat, Dec 1, 2018 at 4:07 AM Hugh Glaser <hugh@glasers.org> wrote:

> Hi David,
>
> > On 30 Nov 2018, at 19:38, David Booth <david@dbooth.org> wrote:
> >
> > Hi Hugh,
> >
> > I suggest we call this "URI *Collapsing*" instead of "Colliding",
> because the WebArch already defines "URI Collision" as "Using the same URI
> to directly identify different resources", which is not what we want:
> > https://www.w3.org/TR/webarch/#URI-collision
> OK, yeah - fine.
> Although if you wanted it different term, I would have thought “URI
> Collusion” would have been the mot juste & mot de nos jours :-)
> I’m not sure it is “Collapsing”, but I would never want to get hung up on
> a name, so fine.
> Although actually, “URI Collusion” has really grown on me, to be honest.
>
> >
> > More below . . . .
> >
> > On 11/30/18 12:22 PM, Hugh Glaser wrote:
> >>
> >> And this would encompass the knowledge that “William Hill” is the same
> name as “Bill Hill”, even if they aren’t the same person, if we wanted.
> >
> > Interesting.  I can definitely see how that could be useful.  However, I
> would caution against automatically saying that "William Hill" is the same
> name as "Bill Hill", because there are communities where a child is
> traditionally named after a parent's nickname.   So if William's nickname
> was Bill, he might have a child whose formal name is actually Bill.  But
> this is a slight digression.
> >
> Absolutely.
> I picked it deliberately to tease out the sort of thing that will be a
> typical issue - my sons are called Benny & Roni (and deliberately not
> called Benjamin or Ronald, because I dislike those names, and especially
> how they are pronounced in some other languages that matter to me).
> But just because there is a person called Bill Hill, who isn’t called
> William Hill doesn’t mean that the name William Hill is not the same name
> as Bill Hill.
> And I bet you my sons have been called Ronald or Benjamin by some people
> sometimes.
> If we get that far, there will be a lot of those sorts of discussion.
> But of course you can have different equivalence datasets that have
> different policies.
>
> By the way, if I seem to be ignoring context, it may be because I can’t
> get to see much web at the moment (which includes your GDoc summary sheet),
> and I can’t get to your original message, or quite a lot of others - sorry.
>
> So we seem all (you and I) agreed.
> I guess that may end the sub-thread; so what now?
>
> Best
> Hugh
>