Re: InverseFunctional Property based Reasoning & Inference

út 21. 2. 2023 v 17:04 odesílatel Kingsley Idehen <kidehen@openlinksw.com>
napsal:

>
> On 2/20/23 4:48 AM, Melvin Carvalho wrote:
>
>
>
> út 14. 2. 2023 v 17:03 odesílatel Kingsley Idehen <kidehen@openlinksw.com>
> napsal:
>
>>
>> On 2/10/23 8:56 PM, Melvin Carvalho wrote:
>>
>>
>>
>> út 17. 1. 2023 v 15:55 odesílatel Kingsley Idehen <kidehen@openlinksw.com>
>> napsal:
>>
>>>
>>> On 1/15/23 8:12 AM, Henry Story wrote:
>>>
>>>
>>> Hi Henry and others,
>>>
>>>
>>> >> On 14. Jan 2023, at 08:19, angelo.veltens@online.de wrote:
>>> >>
>>> >> Thanks Henry , this is an important point to make. So having "copies"
>>> of data like Ruben states it is actually not a problem, but a feature to
>>> express different points of views of the world. I could have a birth date
>>> in an official birth certificate, as well as in my address book and in my
>>> list of birthdays. All of these documents can have different permissions
>>> and different amounts of trust. It could even considered to be a feature
>>> that I can be able to lie about a birthdate in one document, while I could
>>> use the signed birth certificate in places where it matters.
>>> > It is not just a feature, but a necessity.
>>>
>>>
>>> Yes, the goal is to have a system rooted in unambiguous identity which
>>> is what identifiers constructed using Linked Data principles are about
>>> -- fundamentally.
>>>
>>>
>>> > Solid is not about just having a POD
>>> > to store just one’s own data, but to link to data on other pods,
>>> maintained by
>>> > others. If the main use case of Solid were just to store one’s own
>>> data on one’s
>>> > own server then we could go back to the 1980s and use a PCs with
>>> Windows 3.1.
>>>
>>>
>>> Yes, I always believed Solid was about applying Linked Data principles
>>> to read-write operations associated with a Data Space / Pod.
>>>
>>> As per Windows 3.1 analogy, that's how life was before global adoption
>>> of the HTTP protocol that enabled the World Wide Web.
>>>
>>>
>>> >
>>> > I should not be updating the telephone numbers, addresses or
>>> birthdates of my friends
>>> > on my POD, rather I should link to their profiles where they keep that
>>> information
>>> > updated.
>>>
>>>
>>> Yes, there are specific machine computable relationship type (relations)
>>> semantics for handling personally identifiable information e.g., inverse
>>> functionality as per the owl:InverseFunctional property type defined in
>>> the OWL Ontology.
>>>
>>> Basically, reconciling disparate identities is a reasoning and inference
>>> matter.
>>>
>>
>> Thanks Kingsley 💯
>>
>> Possibly warrants a new thread, but do you have some modern examples of
>> how InverseFunctinoal properties (IFP) can work in the real world?
>>
>> It seems to be that there is a lot of value here in being able to stitch
>> together different pieces of software and giving users a better experience,
>> and integration with the social web
>>
>> I am aware of how it works in tabulator / mashlib (solidOS) with
>> smushing, FOAF and other historical patterns +
>> https://www.w3.org/wiki/InverseFunctionalProperty
>>
>> Do you have a recipe or example of how IFPs are currently deployed in
>> "production"?
>>
>>
>> Hi Melvin,
>>
>> Yes, it boils down to a server applying reasoning and inference informed
>> by the entity relationship type semantics of an inverse-functional
>> relation. For instance, foaf:mbox is well defined for making such
>> inferences.
>>
>> Related
>>
>> 1.
>> https://medium.com/virtuoso-blog/using-a-semantic-web-of-linked-data-to-reconcile-disparate-identities-83ab7a315568
>>
>> 2.
>> https://github.com/OpenLinkSoftware/SPASQL-Utility-Showcase-Queries/blob/master/kidehen-ifp-reasoning-test.sql
>>
>
> Thanks Kingsley, that's a great blog post.
>
> I like the way it ties together different identities (webid, twitter,
> linkedin) -- I think this has a lot of value
>
> It seems to me from the profile point of view you just add a predicate
> from a vocab, and the vocab uses owl.  The rules was inserted, but I think
> can be inferred from the library, such as SolidOS.  Then the query or
> lookup uses those inferencess.  Again I think SolidOS could do this, I'd
> need to check.
>
> The example you gave was with foaf:mbox with solid/webID
>
> There is an issue with using foaf mbox in that
> - not everyone likes to make their mbox public
> - there are other identifiers that people use that are IFP
>
> We are also missing a predicate to use your webid/solidID itself as a
> predicate from another profile, would that be a useful IFP?
>
>
> Hi Melvin,
>
> Co-reference is handled via an owl:sameAs relation.
>
> Example
>
> { <mySolidWebID> owl:sameAs <some-other-dataspace-netid>} .
>
>
> Other relations can be designated as being inverse-functional too, if you
> want the owl:sameAs relation inferred -- as long as said relation is that
> way inclined.
>
> Everything is in place, tools just need to make use of the relations that
> exist based on semantics defined in their respective ontologies -- IMHO .
>

Concrete example:

An ActivitPub Actor has a Solid WebID

What predicate would they put in in their profile page?

You could say

</user> ows:sameAs <webid#me>

but that seems a bit broad, and maybe not correct for the Actor/WebID pair
-- maybe it would work I dont know -- perhaps you've tried this already?

Alternative approaches:

1. subclass sameAs
2. a "webid" predicate
3. use owl:sameAs

Let's say I want to follow my nose to find someone's Pod storage.  What's a
pragmatic approach -- I think I'd lean towards (2) right now, though webid
definition is a bit old, and perhaps not 100% nailed down.

>
> Kingsley
>
>
>>
>> Kingsley
>>
>>
>>>
>>>
>>>
>>> > (I should of course be able to keep a historical cache of what I saw,
>>> so that
>>> > egregious changes can be spotted). How do I do that? I have my WebID
>>> link to various
>>> > typed foaf:Groups, which each link to the WebID of my friends,
>>> Colleagues, etc…
>>> > on their pods, wherever they chose to place it.
>>>
>>>
>>> Yes.
>>>
>>>
>>> >
>>> >> But still the practical problems for Solid app developers persist.
>>> When does which app update what data? The brithday app and the contacts app
>>> would write to different documents and the promise of data re-use is not
>>> fulfilled.
>>> >> Perhaps the birthday app could have a feature to copy dates from my
>>> contacts of I give the permission, but it all leaves the problem of keeping
>>> data in sync that Ruben addresses.
>>> > One way to keep things in sync is for example not to duplicate
>>> birthday information
>>> > all over the place. Should I keep track of the birthdays of the people
>>> I know, or should
>>> > they make that available? I think that should be located on each
>>> indificual’s pod
>>> > in a way that is discoverable from the WebID by following ontologies
>>> that gain traction.
>>> > That is the standards part that TimBL was referring to.
>>> >
>>> > This makes even more sense for phone number, living addresses, etc…
>>> There is
>>> > a pragmatic incentive to avoid duplication of information, just
>>> because duplication
>>> > is expensive.
>>> >
>>> > Now if you write apps that follow links in linked data, then where you
>>> place the data
>>> > is a lot more flexible. You could place everything in one document,
>>> say like I
>>> > do with my WebID https://bblfish <https://bblfish/
>>> >.net/people/henry/card#me
>>> >
>>> > Or you could place the main information in your WebID profile and
>>> place groups
>>> > in different resources, with different protection levels presumabley,
>>> >
>>> > <#me> a foaf:Person;
>>> >     foaf:name ”Henry Story”
>>> >     foaf:group [ owl:sameAs </groups/friends#>;
>>> >                  a solid:FriendGroup;
>>> >                  foaf:name ”Group of Henry’s Friends”
>>> >                ];
>>> >     foaf:group [ owl:sameAs <https://co-operating.systems/groups/team#>
>>> ;
>>> >                  foaf:name ”Co-Operating Systems Team” ];
>>> >     foaf:group [ owl:sameAs </groups/family#> ;
>>> >                  foaf:name ”Henry’s family” ];
>>> >     medical:record <https://nhs.org/2023432/> .
>>> >
>>> > etc…
>>> > Using linked data it is very easy to split the data into varioos
>>> equivalent
>>> > sets of graphs in a way that would allow a client to find the data
>>> > irrespective of its layout by following links.
>>> >
>>> > For that one needs good client libraries. I gave a talk end of
>>> december 2014 on
>>> > such a library
>>> >    https://github.com/banana-rdf/banana-rdf/wiki
>>> >
>>> > Somehow I spent a few years then studying Category Theory to make sure
>>> I was
>>> > thinking about this right. I got back to building this where I left
>>> off then in
>>> > the past 2 years. The latest work is linked to from here:
>>> >
>>> >    https://github.com/co-operating-systems/solid-control
>>> >
>>> > Don’t hesitate to contact me, to get a view of where things stand.
>>> >
>>> > Henry Story
>>>
>>>
>>> As per my comment above, tools need to understand the importance of
>>> unambiguous identity, identity authenticity, access controls, and
>>> reasoning informed by relations semantics.
>>>
>>> I've always seen Solid as an effort to simplify loose-coupling of the
>>> following items for app developers:
>>>
>>> 1. Identity -- via identifiers constructed using Linked Data principles
>>> 2. Identification -- credentials (or profile) documents comprising
>>> relations where subject and objects are denoted by identifiers
>>> (constructed using Linked Data Principles)
>>> 3. Authentication -- various protocols for verifying credentials
>>> 4. Authorization -- access controls informed by reasoning and inference
>>> applied to identity principals, groups, and resources
>>> 5. Storage -- Filesytem or DBMS modalities
>>>
>>> IMHO, these issues shouldn't be contentious circa 2023.
>>>
>>> Happy New Year!
>>>
>>> Kingsley
>>>
>>> >
>>> >> Kind regards
>>> >> Angelo
>>> >>
>>> >> Sent from MailDroid
>>> >>
>>> >> -----Original Message-----
>>> >> From: Henry Story <henry.story@gmail.com>
>>> >> To: public-solid <public-solid@w3.org>
>>> >> Cc: Melvin Carvalho <melvincarvalho@gmail.com>
>>> >> Sent: Fr., 13 Jan. 2023 21:39
>>> >> Subject: Re: Detailed response to Ruben's blog
>>> >>
>>> >> Hi Melvin,
>>> >>
>>> >> Thanks for alerting us to this discussion.
>>> >>
>>> >>> On 12. Jan 2023, at 14:58, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>> >>>
>>> >>> IMHO, Insightful article on Solid architecture from TimBL.  I found
>>> myself agreeing.
>>> >>>
>>> >>> Worth a read.  In particular, I liked this observation:
>>> >>>
>>> >>> "The Pod, in RDF terms, is a quadstore, not a triple store. A
>>> triples store is not powerful enough. The 4th part of the quad, the ID of
>>> the graph, we call a 'Document' to make it match with the way people talk.
>>> They might be called Named Graphs or Linked Data Resources but "Documents"
>>> is simpler. The fact that the ;inked data in a pod is basically a set of
>>> distinct graphs is really important."
>>> >>>
>>> >>> https://www.w3.org/DesignIssues/2023/RubenBlogResponse.html
>>> >>
>>> >> Yes, that is the key argument. Graphs stores are good for expressing
>>> one perspective
>>> >> on the world, one coherent point of view. Each new relation added to
>>> the store
>>> >> is one more monotonic fact added to the database. It brings with it
>>> the view of truth
>>> >> as a (maximal) database of facts. Pushed to the logical conclusion we
>>> end up with a
>>> >> possible world: the complete set of coherent facts about a world.
>>> >>
>>> >> But
>>> >> 1. no person is perfectly consistent or knows everything
>>> >> 2. the world is full of competing and cooperating agents
>>> >> 3. truth is discovered by a dialogic process, of argument and
>>> counterargument,
>>> >>    of asking for and giving reasons for one’s statement.
>>> >>
>>> >> So just that means we need ways to seperate perspectives, statements,
>>> ...
>>> >>
>>> >> In a plain graph database one can only deal with this inconsistency
>>> >> by refusing to do reasoning. And indeed those databases don’t do
>>> reasoning.
>>> >> They could not, unless they enforced one oracle to manage the truth
>>> >> of all statements. That could work for one organisations, but it
>>> >> won’t for the world wide web. Just think of China, Russia, US, Saudi
>>> Arabia,
>>> >> Japan, Israel, Palestine, and all the other countries as agents, each
>>> of
>>> >> which having very different interests and points of views. The world
>>> is
>>> >> a multi-agent system since a billion years at least.
>>> >>
>>> >> A document is a statement of something by someone in a certain mode
>>> >> (could be fictional mode or factual). The fourth element of our quads
>>> >> is what is needed to name the result of the act of saying something.
>>> >> The same graph produced in two different places is not the same
>>> saying,
>>> >> and may have very different trust properties for example, even if they
>>> >> have the same meaning. The statement by a doctor that I should take
>>> some
>>> >> medication does not have the same value as someone in a bar telling
>>> me to.
>>> >>
>>> >> One can it is true accomodate multiple sayings in a graph database:
>>> >> by turning the nodes for individual RDF graphs into a node of type
>>> >> rdf:XMLLiteral with a content that would be an RDF/XML string. But the
>>> >> nodes would be opaque to the reasoning of the rest of the graph, just
>>> as
>>> >> named graphs in a quad store don’t interact, unless one asserts a
>>> number
>>> >> of them to be true, or true in a world, or true in a point of view.
>>> >>
>>> >> Next. If we look at the naming hierarchy dimension of Ruben’s
>>> argument.
>>> >> Oddly Ruben only mentions the placing of files on the file system and
>>> >> the naming of those hierarchied but I did not see anything about
>>> following
>>> >> links to find the data. This is the error made by the Web 2.0 APIs in
>>> current
>>> >> use: they set a fixed URL naming framework for placing data on the
>>> web, instead of
>>> >> working with a linked data ontology, where following links is the way
>>> to
>>> >> find the data. In that case the location of the data is relatively
>>> >> unimportant. That is what I thought HATEOAS was about [1].
>>> >>
>>> >> Henry
>>> >>
>>> >> PS.
>>> >>
>>> >> * The original blog post by Verborgh is:
>>> >>    https://ruben.verborgh.org/blog/2022/12/30/lets-talk-about-pods/
>>> >>
>>> >> * And thanks Melving for pointing to the archived version
>>> >>
>>> https://cloudflare-ipfs.com/ipfs/QmSB8WpxXAtd3Ny9G2ZsW39RJnRsfAt2X6Q7iNTGGWo9HE
>>> >>
>>> >> [1] https://en.wikipedia.org/wiki/HATEOAS
>>> >>     "Hypermedia as the Engine of Application State"
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>>
>>> --
>>> Regards,
>>>
>>> Kingsley Idehen
>>> Founder & CEO
>>> OpenLink Software
>>> Home Page: http://www.openlinksw.com
>>> Community Support: https://community.openlinksw.com
>>> Weblogs (Blogs):
>>> Company Blog: https://medium.com/openlink-software-blog
>>> Virtuoso Blog: https://medium.com/virtuoso-blog
>>> Data Access Drivers Blog:
>>> https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>>>
>>> Personal Weblogs (Blogs):
>>> Medium Blog: https://medium.com/@kidehen
>>> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
>>>                http://kidehen.blogspot.com
>>>
>>> Profile Pages:
>>> Pinterest: https://www.pinterest.com/kidehen/
>>> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
>>> Twitter: https://twitter.com/kidehen
>>> Google+: https://plus.google.com/+KingsleyIdehen/about
>>> LinkedIn: http://www.linkedin.com/in/kidehen
>>>
>>> Web Identities (WebID):
>>> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
>>>          :
>>> http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>>>
>>>
>>>
>> --
>> Regards,
>>
>> Kingsley Idehen 
>> Founder & CEO
>> OpenLink Software
>> Home Page: http://www.openlinksw.com
>> Community Support: https://community.openlinksw.com
>> Weblogs (Blogs):
>> Company Blog: https://medium.com/openlink-software-blog
>> Virtuoso Blog: https://medium.com/virtuoso-blog
>> Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>>
>> Personal Weblogs (Blogs):
>> Medium Blog: https://medium.com/@kidehen
>> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
>>               http://kidehen.blogspot.com
>>
>> Profile Pages:
>> Pinterest: https://www.pinterest.com/kidehen/
>> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
>> Twitter: https://twitter.com/kidehen
>> Google+: https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn: http://www.linkedin.com/in/kidehen
>>
>> Web Identities (WebID):
>> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
>>         : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>>
>>
> --
> Regards,
>
> Kingsley Idehen 
> Founder & CEO
> OpenLink Software
> Home Page: http://www.openlinksw.com
> Community Support: https://community.openlinksw.com
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog
> Virtuoso Blog: https://medium.com/virtuoso-blog
> Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>
> Personal Weblogs (Blogs):
> Medium Blog: https://medium.com/@kidehen
> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
>               http://kidehen.blogspot.com
>
> Profile Pages:
> Pinterest: https://www.pinterest.com/kidehen/
> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
> Twitter: https://twitter.com/kidehen
> Google+: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn: http://www.linkedin.com/in/kidehen
>
> Web Identities (WebID):
> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
>         : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>
>