A community tool for interoperability

@cristianvasquez thanks for sharing this.

Two specific questions come to mind:

  • What do you consider the relationship between ontology views and shapes?
  • What is the status of the web blackboard network idea? Have you/others been using it? It seems to be quite closely related to the idea of federated wikis? see Distributed Wiki's on Solid
1 Like

That post is by @how who is also admin at SocialHub. He’s involved in DREAM research, I believe most recently in UPSYCLE.

I think these insights are one of the major factors that stood in the way of the Semantic Web success, as it is near impossible to describe semantics in a universal way, globally machine-readable. At TerminusDB they wrote a 5-part blog series addressing many issues and shortcomings. And in part 3 they talk about open and closed world reasoning.

On the whole set of standards surrounding RDF they say “This is where things get both really brilliant and ridiculously absurd”. SHACL is also mentioned: “the standard that came out was once again full of logical inconsistencies and impractical and wrong design decisions”.

Whatever you think of that, their decision was to focus on closed world vocabularies. And that has an appeal to me, making app design much more practical. And this fits really well with DDD strategic design where a bounded context maps onto a vocabulary. They can be agreed upon and standardized for specific application/business domains. In the case of Fediverse you can create ActivityStreams exensions also defined as separate vocabularies, specifying in this case federated msg formats, and these can be the basis for a more building-block-like approach to app development.

There’s much complexity to tackle, of course, but I hope that with Linked Data, AS/AP and Solid we can move from silo-first to task-oriented federated app design. I have my eye on Go-Fed where you start with a vocabulary defined in a subset of OWL, generate code from that, and then build your (modular) logic and UI on top of that.

We also have a topic on distributed (well… federated) wiki’s going at SocialHub: Exploring semantic knowledge base solutions - Fediverse Futures - SocialHub

1 Like

That is just an old term I used in the slides. Probably now, I would call it ‘schema,’ to avoid confusion.

It was ignored; I believe the dominant idea was to only use ‘global semantics.’ I moved on to other things.

I think this is relevant stuff! Especially now the ‘tools for thoughts’ of the last two years. There is a lot of data produced by thousands of people that ‘weave’ their personal data-spaces (or text-spaces) using tools like obsidian.md, roam, foam, org-foam, to name a few. I see lots of enthusiastic people asking themselves in their respective forums: how we connect our thoughts? How we collaborate?

I’m also open to experimenting. I would start connecting existent vaults, always honoring their representation formats. Afterward, perhaps, add SOLID adapters; :smiley:

DREAM looks useful; I will look into that.

…, the open-world assumption shoe does not always fit. We can use both assumptions and be explicit of which parts of the knowledge should be considered complete and which could be seen as incomplete. We lack of simple enough mechanisms to partition triples though.

This looks like a good pointer. Where can I learn more about this? Do you recommend a comprehensive source?

Funny enough, the name I always wanted to use was ‘meme’ :slight_smile:

You can compose a new concept, relating the mermaid and the tail concepts. But you pay in complexity.

Perhaps modern statistical models, like neural graph networks, can make these things easier for the user. A model trained with your data could tell if the tail is important or not for you after all,

How do you imagine this? in what sense would this be useful?

1 Like

With Fediverse having grown in grassroots fashion from the 3 specs AS Core / AS Vocab and ActivityPub, I am afraid that good documentation are still lacking in depth and quality. Mastodon has been the early adopter and filling holes in the spec (with WebFinger, HTTP Signatures, NodeInfo). These things were discussed in the W3C SocialCG and SocialHub.

Onboarding for new devs is still quite hard, though there is some documentation, like Guide for new ActivityPub implementers. But if you want to see how extensions are applied in the wild, then you need to often dive into codebases. Like e.g. PeerTube defines video vocabulary extensions (e.g. a Video object) in their typescript code. Other extensions are more clearly specified, like ForgeFed protocol. Here are watchlists of apps and dev resources.

The closed world perspective simply means that your vocabulary only has a well-defined meaning for those who accept it. An agreed upon convention. You don’t worry about concerns that go beyond that, e.g. having a global standard or semantics that can be universally understood and translated to arbitrary other similar semantic models.

This may still go well beyond an (application) silo. Like e.g. for Fediverse I want agreement on what a Community entails. Create a vocabulary for that, which extends ActivityStreams. The latter offers as:Group, but there’s more to community than that. The community vocabulary (or bounded context in DDD terminology) thus created might be adopted fediverse-wide, but also elsewhere. Like e.g. for Valueflows. And in Solid apps too.

I guess the trick is not to specify too much, only the bare minimum. For instance I’ve found ‘community’ vocabularies that would only apply to a forum.

The idea of avoiding application silo’s and go towards task-oriented design is related, but different. Mostly it boils down to not consider interoperability as an afterthought, after the entire app has already been built. It is more oriented to the methodology applied to app design.

As I understood:

Natural language → RDF → Apps use the RDF (with queries)

People could use it to connect and expose any kind of text as RDF from a pod. Process the word documents of your folder, chat conversations, Facebook interactions. The contents of this forum. I would bet for adapters that do that (they call them ‘triplifiers’)

Hi @justin

I can see there is a lot of discussion on the ‘schema’ aspect of interoperability, but it misses (o or I cannot find ) the ‘agreed semantics’ aspect.

To exemplify:

Suppose an app, for example, wants to use some info in the profile. In that case, it can execute queries, apply rules, follow links, consume APIs, transform data into any intermediary structure you want.

But the app will always need to be careful to interpret vocabulary one, vocabulary two, etc. Or, more precisely, the app needs to act in a way it’s expected (and accepted) by the owner of the Pod.

The pod owner will always have something to say. An app can (probably will) use statistical models to interpret or map the vocabs, but the Pod owner should agree with the result.

I miss a mechanism where the user can ‘commit’ to some vocabs.

I imagine that perhaps a Pod owner can use a community tool for interoperability’ for that; for example, in the user profile case, the user inspects examples of profiles to say afterward: yeah! That’s what I also understand as a profile. There are many techniques to do that.

Can I see the slides? or a shorter synopsis? :slight_smile:

I suppose currently the idea is that a user advertises the shapes they have registered and apps are encouraged to comply with them.

From that point of view, I suppose the next step is to give more visibility to the vocab choices that users and apps are actually selecting, and given that users are unlikely to be aware of the details this comes down to visibility of which shapes apps in the same domain are choosing to support.

While this partly returns to earlier points in this conversation, perhaps a simple best practice should be that apps request user consent before registering a new shape, and that the shape is described in both human and machine readable format, perhaps offering additional explanations with some disclosure about alternatives and potential tradeoffs. This might also encourage apps to support multiple competing shapes.

Asking consent for data shapes seems to go against the trend towards reducing friction in user interaction, but on the other hand might be necessary for the user to gain any meaningful control over their pod and the data within it?

Yes, it would help to know what people are using to share their data. That’s where a networked Web of shapes (or blackboards, whatever) would help. If two organizations discover what shapes are being used for the same thing; they can plan to merge them.

I think that ideally, a person should understand what is in their Pod. A person can, for example, have a map of contents (MOC) of what’s in the Pod, things like having a 'simple profile shape ’ and a ‘detailed work profile shape’ subsumed in a big circle ‘me seen by the others’ (name chosen by the person, with relevant annotations and stats ) …

The user maintains their data, curating, cleaning, augmenting, using different (interchangeable) apps. This is called ‘digital gardening’ by the current Personal Wikis applications.

… I would add to show in the screen the actual data to be shared (show the query results the app wants to consume).

Yeah!, with the right amount of detail. To be able to use the less complex and versatile one that does the job. Or move into complex ones if necessary.

… I think that ‘lack of trust’ could be a major factor of friction, and trust comes with meaningful control and understanding of what’s going on.

I like the intuition of a ‘set of queries’ because the user can ‘see the results’ and accept them or not.

Maybe it would be worth trying it. :D. Also, why a vector and not just a query? On the other hand, you could have a statistical model (or neural network) trained with your Pod’s data that shows a beautiful song, according to you. Can this be seen as a query?

Probably the meme part comes when you share, copy and merge those models between pods.

I think this topic is relevant to interoperability, but perhaps not necessarily at the ‘applications’ level. Maybe it is more related to exchanging data modeled using the user’s mental model. Using the desktop as an example, I know exactly where specific documents are on my computer. Still, probably it would be difficult for me to find the same in your folder structure—that kind of interoperability.

If I use a Pod, I don’t necessarily want to delegate trust to an assistant. I want the assistant to augment my capabilities, but I still want to decide.

For example, today, without a POD, I maintain a ten year old personal wiki where I write some facts and impressions about the people I interact with. Sometimes I review this history to support an objective decision of trusting or not. Perhaps an assistant can help to gather valuable data to do this kind of thing for me.

I believe the same.

I think ontologies/shapes/schemas/vocabs/hashtags are beneficial when you have to integrate and query things in the open

But when you talk about personal dataspaces, perhaps this becomes more nuanced.

Example: The Solid App specializes in promoting comedy shows. Suddenly ‘Bob’ is scared with the clowns shown to him. He gives feedback, and for Bob, the ‘clown’ ontology drops a ‘is funny’ statement.

However, the app starts getting similar feedback from everyone in Bob’s superstitious town (probably because of an old tale of a killer clown). The town (community) drops as a whole the ‘is funny’ statement.

Note this correction happens in the comedy shows pod, or Bob’s pod, or in Bob’s community Pod, who knows :slight_smile:

Or a git-like mechanism that allows fork and merge a bunch of info (identified shapes, app, data sources, time, etc)

A rule language that is a pleasure to work with is N3

Tutorial:
https://n3.restdesc.org/rules/executing-rules/

Examples of mappings (owl, rdfs…)
http://eulersharp.sourceforge.net/

And vice-versa,
a rule language (like N3) can be used as a (different) query language

2 Likes

If I pose that all of this seems highly complex and in very early stages to find broad adoption anytime soon, do you feel that is an accurate statement, or do you have a much more positive take?

Sure, and that is great. I wouldn’t discourage anyone from doing so (am doing so myself at SocialHub). I was just wondering how much need to be done on this interop front, and how the gradual path to adoption might look like. Also those devs already involved with these things might find it less complicated in practice to implement.

Well realistically the most likely outcome in the short term is dominant apps that manage to impose their preferred shape, which others then have to follow, i.e. same thing we have now but in RDF on a user’s pod. It’d be nice if we could aim higher.

4 Likes

This seems like level 0 we should be aiming for, because if a dominant app is imposing a shape it doesn’t even need to do that.

Perhaps how much need to be done depends on the use cases defined?

I have the same feeling when I see this through a particular angle:
Pod with apps on top is not so different from a mobile phone with some installed apps. But now solid is using RDF instead of a plain JSON or just a binary.

However, you can immediately argue that thanks to RDF, integrating different data sources becomes exceptionally cheap, meaning that you can combine and consolidate contents from varied personal data spaces with unprecedented granularity.

And with Web identifiers, people can combine their data to, for example, collaborate without third parties involved. People are empowered to form new sociotechnical systems, interaction mechanisms, etc.

The magic does not happen in the Pod-App duality, but in the combination of dataspaces, when people share and interact together. However, one cannot forget that RDF is not cheap; you pay in complexity. And complexity determines how much your system can grow.

There are also other (perhaps simpler) ways to integrate personal spaces using RDF. For example, one can make RDF triplifiers/adapters on top of the major mobile OS. There are already ~5.27 Billion people with mobile phones in the world.

I would love it that there was more research on what happens with semantics in decentralized environments.

edit: … in the semantic web community

Sure, but I am referring to what would be a good practical and operational starting point, that isn’t very likely to be a dead-end compatibility-wise once specifications mature.