primaryTopic vs isPrimaryTopicOf

[melvincarvalho]

The rough draft context drafted by @acoburn contains two terms:

• primaryTopic
• primaryTopicOf

https://github.com/webidcg/webid-context/blob/main/webid.json

I checked in FOAF and the latter does not exist.

However it might solve some big interoperability hurdles.

For example some tooling struggles to handle nested structures, such as activitypub

Might it be an idea to have a simple json object as a webid that is NOT nested, and this would require an inverse of primaryTopic, if such a thing exists. If not could we make one?

I lean towards this simple solution as a vector simplicity and broader adoption

[melvincarvalho]

Schema.org is a phenomenal success

Indeed, schema has massive adoption. WebID currently has relatively little adoption. By aligning with schema, it gives WebID a chance to enter the mainstream, and schema gets an interesting social element to it, which can be easily glued together with the emerging open social web. It's a great win-win, and very easy to do.

[melvincarvalho]

foaf:primaryTopic and schema:mainEntity mean the same thing.

Making that part of schema.org would be useful, generally. That said, it doesn't address the viewpoint that espouses the use of both in the WebID spec.

If they mean the same thing (which is great!), it doesnt matter too much which you use.

They could be aliased to each other using OWL, I think?

Similarly if the inverse and forward relations have trade-offs but mean the same thing. So long as they are not prohibited, then everyone can work. However, simplicity and existing adoption normally show themselves to be competitive advantages, in this respect.

In general these things tend to get solved by good examples or a primer. Web developers copy and paste examples, and are ready to go on the social web. I could consider writing a WebID Primer in the medium term, if there's interest.

[jonassmedegaard]

They could be aliased to each other using OWL, I think?

...so you directly disagree with @woutermont that they "at most partially overlapping classes, not equivalent ones"?

Do you think that we should go ahead and assume equivalency, despite not yet existing, or do you think that popularity of schema.org is so important for WebID that we should wait for equivalency to get declared before we move on defining WebID?

Personally, I am still of the opinion that those millions of schema.org fans do not care if WebID use a different word at its core, and a different word is more exact for WebID which is helfup for those few that do apply reasoning to WebID expressions.

[kidehen]

Seems to me that if web developers don't really care about semantics, but others do, then there is no need for us to please web developers with specific semantic vocabulary: They don't really care!

Here's the problem that I am trying to address, with additional clarity:

"Web Developers" are important because they are going to build the apps that leverage what a WebID offers.

"Semantic Web Aficionados" haven't historically matched "Web Developers" when it comes to developing and publishing widely used applications.

As both Schema.org and JSON-LD have demonstrated, the "Web Developer" persona is a valuable target if application creation and publication is vital.

Examples?

1. Fediverse
2. Web Pages comprising enhanced metadata

I can expand more on this issue, if need be.

[kidehen]

They could be aliased to each other using OWL, I think?

The FOAF Ontology/Vocabulary simply needs to include an owl:equivalentProperty or rdfs:subPropertyOf relation. Personally, I prefer rdfs:subPropertyOf due to ambiguity issues that exist in how Schema.org entities are named.

[jonassmedegaard]

I get your point that "Web Developers" are important.

It is my understanding that "Semantic Web Aficionados" are (literally, so not really surprising) picky about semantics.

What I fail to understand is how "Web Developers" being important leads to schema.org being important. I doubt that you mean to imply that "Web Developers" are anti-semantic, so there must be something else that I am missing here.

[kidehen]

What I fail to understand is how "Web Developers" being important leads to schema.org being important. I doubt that you mean to imply that "Web Developers" are anti-semantic, so there must be something else that I am missing here.

"Web Developers" are the ones creating solutions to inject RDF into HTML-hosted structured data islands using Schema.org terms. They are also the one's building apps like Mastodon that use ActivityStreams which underlie the ActivityPub protocol etc..

The irony here is that the folks that supposedly don't care about RDF are the ones churning out RDF applications that are in broad use. Why? Because historical barriers have been deftly taken off the table in order to drive broader (albeit imperfect) progress. This phenomena exists because, in the minds of many, RDF & XML remain inextricably linked -- even though many of us have tried over the years to fix that terrible misconception.

This is also what I mean whenever I invoke the "Wisdom of Solomon" phrase i.e., keeping RDF alive rather than killing it on the basis of semantic purity; fundamentally, anyone that really understands RDF would also possess the skills necessary for transforming data en route to localizing semantic purity.

An HTTP URI as a WebID offers phenomenal power for solving many currently unsolved problems, even more so in the age of LLM-based tools such as ChatGPT and friends. Unfortunately, if the WebID spec remains stuck in its current state, something else will replace it.

[csarven]

It seems there are a couple of possible things to do here. One is on the FOAF and/or schema.org definition end. Those are controlled / being worked on by other groups and communities. So, best we can do here is follow-up / rely on their definitions.

As for what's relevant and doable for the WebID specification, I'll use the following example to make a point on authoring/editorial suggestion:

https://www.w3.org/TR/activitystreams-core/#media-type

Because Activity Streams 2.0 can be considered a restricted profile of JSON-LD, Implementations SHOULD consider the application/ld+json; profile="https://www.w3.org/ns/activitystreams" media type as being equivalent to application/activity+json.

another example:

https://www.w3.org/TR/social-web-protocols/#content-representation

ActivityStreams 2.0 content is served with the Content-Type application/activity+json or for JSON-LD extended implementations, application/ld+json; profile="https://www.w3.org/ns/activitystreams". Consumers should recognise both of these Content-Types as ActivityStreams 2.0; they should be treated as equivalent.

In essence, focus on who or what what will be consuming the WebID Profile Documents using schema.org on the wild wild web, instead of focusing on changing existing publications (describing agents) or developers' practises. The former is something we can manage, that's where the WebID spec comes in, but the latter is something far too complicated to manage, quite literally impossible to dictate.

So, assume the relationship between foaf:primaryTopic and schema:mainEntity (or anything else that's of interest) is sufficiently clear, consider text along these lines:

" Implementations that can recognise properties from different vocabularies as being equivalent to foaf:primaryTopic are encouraged to use WebID Profile Documents in the same as described in this specification. "

See https://github.com/w3c/WebID/pull/32 .

IMO, that's the kind of a thing to introduce at this time with minimal friction. There can be more detail, if certain properties and their kind of relationship really needs to be called out (see above for AS2 examples. For example, being explicit on Content Negotiation (by Profile).

If/when there is more implementation experience brought back to this Group, whether through implementation reports, surveys, or something else, that language can be adjusted, removed, or changed to a MUST requirement level.

---

I have much more to say about what constitutes interoperable but that's for another thread :)

[melvincarvalho]

ActivityStreams 2.0 content is served with the Content-Type application/activity+json or for JSON-LD extended implementations, application/ld+json; profile="https://www.w3.org/ns/activitystreams". Consumers should recognise both of these Content-Types as ActivityStreams 2.0; they should be treated as equivalent.

Regarding the historical context, it's regrettable that the decisions during the SWWG led to a division in the W3C social web, specifically between AP and Solid. This divergence has indeed impacted interoperability, which is a cornerstone of standardization. Ongoing efforts to recover from these challenges and promote better alignment, with the moderization of the WebID spec, particularly a JSON upgrade are commendable.

The suggestion to realign profiles and to recognize properties from different vocabularies as ~equivalent, including foaf:primaryTopic, foaf:isPrimaryTopicOf, and schema:mainEntityOfPage, is a valuable contribution.

From our POV so long as we are able to use schema:mainEntityOfPage, that is all we need in order to work.

[jonassmedegaard]

This is also what I mean whenever I invoke the "Wisdom of Solomon" phrase i.e., keeping RDF alive rather than killing it on the basis of semantic purity; fundamentally, anyone that really understands RDF would also possess the skills necessary for transforming data en route to localizing semantic purity.

Sorry, but I still only get from your writing no answer as to why using schema.org is any better. Are you saying that it is wisdom to deliberately avoid clear semantics?

I get that you see no benefit in picking FOAF because those actually using WebID don't care about semanics. What I still don't have is a clear explanation why schema.org is beneficial.

Unfortunately, if the WebID spec remains stuck in its current state, something else will replace it.

Choosing nothing - stalling - is indeed bad for everyone. But stating that as a response to my explicit question about why schema.org is a better choice (rather than the choice being irrelevant for the masses, only relevant for arguably too few), gives the impression that choosing anything but schema.org means stalling - I don't understand.

[melvincarvalho]

I get that you see no benefit in picking FOAF because those actually using WebID don't care about semanics. What I still don't have is a clear explanation why schema.org is beneficial.

@jonassmedegaard schema.org is quite impactful due to its massive network effect. It's widely adopted across millions of websites and billions of pages. This extensive usage significantly surpasses FOAF, positioning schema.org as the de-facto standard for the semantic web

[jonassmedegaard]

how is it (strictly positively, I assume) impactful when a) it has a different semantic meaning, and b) those excited about schema.org don't really care about semantics (those exciting numbers are mostly related to SEO purposes, I assume)?

[melvincarvalho]

those excited about schema.org don't really care about semantics

@jonassmedegaard, I'd like to share a notable point that might not be widely known. Danbri, the creator of FOAF in 2004, is also behind schema.org. The two decades since FOAF's inception have greatly influenced the development of schema.org, which combines rich semantics rooted in RDF with user-friendly deployment options, especially in JSON. It's also noteworthy that our early work, which eventually evolved into WebID and Solid, began on danbri's 'foaf protocols' mailing list. The team at schema.org is deeply committed to semantic web principles, a commitment comparable to the FOAF project, but with significantly broader adoption and support for RDF via JSON-LD. As we acknowledge our history, it's important to include these connections and contributions, Henry's contributions, and tracing back to foaf and foaf-protocols, where many initial implementations occurred and laid the groundwork for where we are today.

Think of schema.org much more than an SEO tool. It's the single most important vector in bringing the semantic web into the mainstream.

[kidehen]

Sorry, but I still only get from your writing no answer as to why using schema.org is any better. Are you saying that it is wisdom to deliberately avoid clear semantics?

There are profile docs like https://www2.deloitte.com/us/en/profiles/beena-ammanath.html/#person all over the place i.e., the notion of using an HTTP URI to unambiguously name agents is happening. The tailwinds are coming from Schema.org adoption.

In my experience, standards work much better (i.e., become broadly adopted) when they formalize what's in use, rather than attempting to prescribe how things should be done.

SeeAlso:

1. https://www2.deloitte.com/us/en/pages/consulting/articles/gen-ai-use-cases.html#fixing-the-missing-data-issue -- see the footer section; also note I've shared other examples of this pattern and its use in the past, from other sources.

[jonassmedegaard]

Great that danbri has worked on multiple projects. Great that schema.org is widely popular and embraced by lots of web developers.

None of that, however, answers my question: What exactly discourages the popular masses from using WebID when defined with a FOAF triple at its heart?

[webr3]

What exactly discourages the popular masses from using WebID when defined with a FOAF triple at its heart?

Much of this may be a symptom of not covering the first step #33

As soon as you define the class of an agent, then you automatically want to define a property which has a domain of document and a range of that agent to link an agent to a document that describes it.

Doing those two things, both provides a core webid superspec that can be relatively constant and stable in time, and also makes most other conversations including this, moot.

[kidehen]

What exactly discourages the popular masses from using WebID when defined with a FOAF triple at its heart?

The fact that FOAF is conflated with RDF, and most "Web Developers" suffer from R-D-F reflux.

BTW -- my earlier examples do not use foaf:primaryTopic or schema:mainEntity, since neither are required for the kind of WebID specification doc that I envisage.

[jonassmedegaard]

What is driving my repeated question here is a strong scepticism that WebID need or benefits from being explicitly locked into schema.org. I fail to see a need for that, I doubt that there is a real benefit from that, and I worry that potentially there might be problems in that.

I am open towards ways to design WebID so that there is neither need for locking into FOAF nor locking into schema.org. I am quite interested in understanding any such options in more detail - and apologize if that has already been spelled out to me and I have simply missed or forgot that.

@kidehen: Please can you elaborate on how you see WebID defined so as to not lock into any specific ontology term, yet still be a formally defined specification? Or point me to where you have already done that.

[webr3]

I am open towards ways to design WebID so that there is neither need for locking into FOAF nor locking into schema.org

+1

[melvincarvalho]

from being explicitly locked into schema.org

Yes, that is fine. It is more the inverse. Someone using schema, that wants to adopt WebID, should not be prohibited from working.

[woutermont]

[@jonassmedegaard:] I am open towards ways to design WebID so that there is neither need for locking into FOAF nor locking into schema.org

Which, as I suggested, can be done by simply minting a new term (but losing backward compatibility in the process^:

If we don't care about backwards compatibility, we can choose whatever predicate we want, and should therefore probably pick a new one like www.w3.org/2005/Incubator/webid/terms#about: this aids semantic expressiveness and validation of the documents.

^ Mind however, that breaking backwards compatibility is i.m.o. more impactful on adoption than anything else we discuss here. Whether or not we like it, people have been creating WebIDs with foaf:primaryTopic for years, both in development and in production.

[kidehen]

What is driving my repeated question here is a strong scepticism that WebID need or benefits from being explicitly locked into schema.org. I fail to see a need for that, I doubt that there is a real benefit from that, and I worry that potentially there might be problems in that.

A WebID doesn't need to be locked to anything. It is an identifier that names an agent unambiguously.

These FOAF and Schema.org attributes come into play because of due to the following being conflated:

1. WebID -- Identifier
2. WebID Profile -- Document (this is where Attributes and Classes only come into play)
3. WebID-TLS -- Authentication Protocol (ditto)

The WebID spec can simply explain unambiguous agent naming using prose.

[jonassmedegaard]

@woutermont: Yes, if we are fine starting from scratch by disregarding both backwards compatibility and "magic massive success" from hitching a ride with SEO giants, then it can indeed be "simply done".

I still miss an explanation why there is a need for disregarding both those.

I see a benefit in caring for backwards compatibility. Not an gigantic benefit, so if someone can explain to me why it is the lesser benefit compared to other benefits then I am all ears. But until then, I do see a benefit in FOAF over minting a new triple.

Yes, that is fine. It is more the inverse. Someone using schema, that wants to adopt WebID, should not be prohibited from working.

@melvincarvalho: Uhm, you choose a different lingo there. I don't think that any scenario discussed so far is prohibiting anything. If you disagree then please clarify what prohibits what.

What I am talking about is that I do not want us to enforce semantics rooted in schema.org. I am not worried about us enforcing semantics rooted in FOAF - because a) FOAF is the ontology already used unofficially among RDF fans for ages, and b) SEO fans do not care about semantics, they just throw in whatever spell making their systems trigger the magic they wanna achieve - i.e. they link their content to whatever JSON-looking template their Google advisory blog post tells them works (which is a JSON-LD file stating some sloppy equivalency between FOAF and Facebook graphs or schema.org or whatever else their html generators already spew out).

The WebID spec can simply explain unambiguous agent naming using prose.

Fine with me to omit any MUST regarding ontologies, in the WebID spec. We can then rehash this conversation when discussing each authentication spec.

Those who think it is required to specify ontology in the WebID spec, please clarify why.

[kidehen]

Years ago, when Linked Data principles and the LOD Cloud were taking shape, we had similar discussions and controversy swirling around the use of an HTTP URI to name anything unambiguously -- where a "#" indexical or 303 redirection where the instruments of indirection that's critical to the essence of a name.

It occurred to me back then, as it does right now re WebID, that specifying the document to which an HTTP URI resolves is much easier than starting from the HTTP URI itself.

For example: Describing the nature of http://dbpedia.org/page/Linked_Data is a much easier starting point for specification than http://dbpedia.org/resource/Linked_Data. Remember, http://dbpedia.org/resource/Linked_Data resolves to http://dbpedia.org/page/Linked_Data -- by way of 303 redirection.

curl -IL http://dbpedia.org/resource/Linked_Data 
HTTP/1.1 303 See Other
Server: nginx/1.18.0
Date: Wed, 03 Jan 2024 21:52:24 GMT
Content-Type: text/html
Content-Length: 153
Connection: keep-alive
Location: https://dbpedia.org/resource/Linked_Data
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: HEAD, GET, POST, OPTIONS
Access-Control-Allow-Headers: Depth,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept-Encoding
....
....
HTTP/1.1 303 See Other
Date: Wed, 03 Jan 2024 21:52:25 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Connection: keep-alive
Server: Virtuoso/08.03.3329 (Linux) x86_64-generic-linux-glibc25  VDB
Location: http://dbpedia.org/page/Linked_data
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: HEAD, GET, POST, OPTIONS
Access-Control-Allow-Headers: Depth,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept-Encoding

Describing and specifying a WebID-Profile Document is much easier than specifying a WebID, since a WebID resolves to a WebID-Profile document i.e., it is one amongst other important and loosely-coupled components used to construct a machine-computable profile that describes an agent.

[melvincarvalho]

I don't think that any scenario discussed so far is prohibiting anything. If you disagree then please clarify what prohibits what.

This is great from my POV! How that is achieved I dont mind too much.

[kidehen]

Solution routes:

1. Fix the title of the current doc, since "WebID and Identity Discovery (WebID)" is utterly broken
2. Or, fork the current spec's content, change its title, and put JSON-LD on a level playing field with Turtle via SHOULD (since we can't have two MUSTs)

1-2 would give us a something that could be titled "WebID Profile Document Specification for JSON-LD" . That document could then evolve to incorporate the schema:mainEntity document attribute alongside foaf:primaryTopic.

How about that for a plan?

@csarven: Can your previously proposed PRs not be applied to this scenario, if we can't find any other way, via consensus, to bring JSON-LD into the mix?

[kidehen]

Choosing nothing - stalling - is indeed bad for everyone. But stating that as a response to my explicit question about why schema.org is a better choice (rather than the choice being irrelevant for the masses, only relevant for arguably too few), gives the impression that choosing anything but schema.org means stalling - I don't understand.

I am not trying to infer anything like that, re the assumption that its schema.org or stalling.

I try my best to always fight for flexibility, by leveraging what's already in place via existing open standards. For instance, RDF at its very core offers a solution for loosely-coupling terms across vocabularies. Thus, incorporating Schema.org simply boils down to which developer-profile is best suited to loosely-coupled integration aided by entity relationship type semantics defined in the relevant vocabulary.

In my experience, RDF-related specs always end up in problematic places when they try to workaround (or ignore) what it offers -- with regards to interoperability informed by vocabularies.

[kidehen]

This extensive usage significantly surpasses FOAF, positioning schema.org as the de-facto standard for the semantic web

My slightly modified take: Schema.org is the de-facto vocabulary for a kind of Semantic Web.

Personally, I believe "The Semantic Web" style of branding regarding the Web's evolution died a long time ago i.e., the notion of "a Semantic Web" is much more palatable and realistic.

[kidehen]

how is it (strictly positively, I assume) impactful when a) it has a different semantic meaning, and b) those excited about schema.org don't really care about semantics (those exciting numbers are mostly related to SEO purposes, I assume)?

Forgive me if I am repeating myself, as I am working through some unanswered posts.

Schema.org has been broadly adopted by the 'Web Developer' persona. This group is responsible for writing and publishing more apps and services than the 'Semantic Web Aficionado' persona. Therefore, engaging the 'Web Developer' persona is a strategic step towards achieving much broader adoption of WebID, WebID-Profile, and WebID-{whatever-authentication-protocol}.

Ultimately, the goal of WebID, WebID-Profile documents, and WebID-based Authentication is to tackle the 'User Controlled Identity' issue. This issue continues to be a significant challenge for web applications developed by 'Web Developers'.

[kidehen]

@kidehen: Could you please elaborate how foaf:primaryTopic conflates Identity, Identification, and Authentication, whereas schema:mainEntity separates Identity, Identification, and Authentication.

You are going to have to provide a link to wherever I made such a statement or insinuation. If anything, it is Schema.org that's guilty of naming of its terms ambiguously, as a deliberate compromise for on-boarding the 'Web Developer' community.

Ambiguity in this case lies in the use of "/" based HTTP URIs for property and class names without the use of 303 redirection for disambiguation of name and address.

[jonassmedegaard]

A WebID doesn't need to be locked to anything. It is an identifier that names an agent unambiguously.

Sorry, I was being imprecise. What I meant to say is that I worry about lock-in of WebID Profile spec with schema.org.

As we later (somewhere - I lost track) seemingly agreed, I see no problem in the WebID Profile spec having lock-in a.k.a. MUST of either FOAF or schema.org.

[jonassmedegaard]

...but for the record, my very concern about schema.org is that it is "slightly" different from FOAF, which may lead to difficulties reasoning robustly. That is however not a problem for WebID spec nor for WebID Profile spec, only for WebID auth-XXX specs. Some WebID auth-XXX specs may then choose to loosen the robustness of the authentication as a traedoff of winning millions of new usable WebIDs, whereas other specs might choose to reason more robustly which in turn may exclude schema.org (or not, if my worries are for no reason, as some here seems to think). That's all fine: WebID auth-XXX specs need not all be compatible.

[woutermont]

To spare my fingers from typing everything out once more: https://github.com/w3c/WebID/pull/32#issuecomment-1878910423 repeats once again very clearly what this is about (spoiler: it is not about developer preferences).

[woutermont]

Let's just give another example to make this clear.

WebID-Lib is a JavaScript library providing some easy functions that check WebID validity and can interact with a large number of WebID authentication profiles (e.g. TLS, OIDC). SomeApp is an application making use of the WebID-Lib. MyID.org is a WebID provider minting WebIDs for people and hosting their WebID Documents. Fran is a person with the WebID https://myid.org/fran#me. Via a nice interface on MyID.org Fran was able to enter her name, age and some other information. She uses SomeApp to do whatever that app does, and SomeApp wants to check her WebID to use her name in the user interface...

Still with me? Now, who will be triggered, motivated, inspired, angry or whatever by our choice for FOAF or Schema.org? The single developer of WebID-Lib? I don't think so (and it would probably be one of us 😄). The developers of MyID.org? They don't give a whoopsie. Both of these put foaf:primaryTopic in a constant called webIdPredicate and soon forget whatever its concrete value was. That's it. No one else has to bother with it. 🤷‍♂️

[kidehen]

Now, who will be triggered, motivated, inspired, angry or whatever by our choice for FOAF or Schema.org?

WebID-Lib developer, since they are the authentication protocol implementer. That also implies ambivalence on the part of anyone (or piece of software) that want's to refer to an agent based on a WebID they've discovered, along the way.

Why? Machine-computable entity relationship type semantics only come into play, in a tangible way, when implementing an authentication protocol.

That's why we need to ensure that a WebID, WebID-Profile Doc, and WebID-{Whatever-Auth-Protocol} are loosely-coupled. Unfortunately, that isn't the case right now.

WebID -- handles Identity WebID-Profile Doc -- handles Identification WebID-{Whatever-Auth-Protocol} -- handles authentication

Additional Background Information:

When I ask, "What is your WebID?" I'm seeking an HTTP URI that functions akin to a resolvable passport number (which only happens in the realm provided by immigration services). Essentially, with regards to the HTTP-based Web, I want to know: How can I refer to you unambiguously?

The concept of WebID was born out of a need for a more socially palatable alternative to phrases like "What is your URI?" or "Get Yourself a URI." Inspired by OpenID, which served similar purposes but wasn't RDF-based, the term "WebID" came into being.

TimBL once authored a blog post titled "Get Yourself an HTTP URI," now lost to time, as it no longer resolves from my old blog post.

You can find a TimBL's "Give yourself a URI" post at: https://web.archive.org/web/20060203052328/http://dig.csail.mit.edu/breadcrumbs/node/71 .

Similarly, the IRC conversation logs that sparked the "aha" moment regarding the choice of "WebID" have also been lost. I mention this as a participant in those discussions, alongside TimBL and the late Henry Story. These conversations occurred years before the WebID specification process began in Paris and elsewhere. (Note to @melvincarvalho).

Unfortunately, the conflation of an HTTP URI with a Profile Document was more a result of branding than technical necessity. The current specification's narrative would have been better focused on defining the nature of a passport document based on a unique passport number, rather than a passport number that can be looked up -- with a passport verification system in mind.

[woutermont]

@kidehen, apart from fact that a WebID handles Identification (not Identity) and WebID Document handles Identity (not Identification), I completely agree with you on keeping these dimensions loosely coupled.

I fail to see, however, how the predicate choice has anything to do with it. It is purely a Document matter: its about validating the Document.

Now, who will be triggered, motivated, inspired, angry or whatever by our choice for FOAF or Schema.org?

WebID-Lib developer, since they are the authentication protocol implementer.

Like I said, they will just put the predicate URI in a constant. What's there to be triggered about? If someone wants to implement a WebID library, they read the spec and copy-paste the predicate, simple as that. And if they have an allergic reaction to FOAF, someone else will write it, and the world will be better for it.

Seriously, not wanting to use a term from FOAF is like refusing to interact with all people called "John". It is just a term.

Machine-computable entity relationship type semantics only come into play, in a tangible way, when implementing an authentication protocol.

This is actually another good point against Schema.org. As long as their vocabulary is not semantically sound, any machine reasoning over a WebID Document will go haywire or, in practice, people writing reasoners will just tell their algorithms to avoid Schema.org terms.

[kidehen]

apart from fact that a WebID handles Identification (not Identity) and WebID Document handles Identity (not Identification), I completely agree with you on keeping these dimensions loosely coupled.

To clarify:

1. Identity -- facilitated by an identifier serving the needs of "denotation"
2. Identification -- facilitated by a document serving the needs of "connotation"

A Name comprises both "denotation" and "connotation" by way of indirection. The indirection mechanism is subject to what's provided by the perception realm within which the name is used.

The real magic of the Web boils down to how HTTP deftly incorporates the above. Unfortunately, said magic comes with a cost i.e., it isn't easy to explain in ways that immediately agreeable :)

[woutermont]

To clarify:

1. Identity -- facilitated by an identifier serving the needs of "denotation"
2. Identification -- facilitated by a document serving the needs of "connotation"

You and I clearly studied in different places. To me:

1. Identity: a set of characteristics of an entity that uniquely determines that identity (e.g. any resource, including agents)
2. Identifier: a minimal identity (e.g. any URI, including WebIDs)
3. Identification: construction of an identity, either by the entity itself (presenting an identity) or by someone else (discovering an identity), often by way of another, preceding identity ('precedence' here meant as in mathematical order).

Both denotation and connotation are forms of identification, in that they refer from one identity (often an identifier) to another.

Then again, this was totally not the main point we were talking about here, and would lead us very far indeed 😄

Edit: @jacoscaz, don't hesitate to hide this sidetrack to maintain at least some direction in this topic.

[kidehen]

1. Identity: a set of characteristics of an entity that uniquely determines that identity (e.g. any resource, including agents)

I am more comfortable with https://www.britannica.com/topic/identity-logic#thisDefinition , that resolves to a page comprising the following snippet:

identity, in logic and metaphysics, a relation that a thing bears to itself and to no other thing.

[woutermont]

That's the identity relation, which is another thing. Yes, the word is quite ambiguous (besides, in metaphysics it is not often used as a relation at all). But let's have this talk somewhere else (perhaps in real life someday) ...

(Again, @jacoscaz, please hide at your own convenience. Sorry for poluting the thread.)

[jonassmedegaard]

Now, who will be triggered, motivated, inspired, angry or whatever by our choice for FOAF or Schema.org?

WebID-Lib developer, since they are the authentication protocol implementer.

Why would WebID-Lib developer be tickled by our choice to specify that WebID-Profile-Foo-easy-peasy MUST use schema.org, WebID-Profile-Bar-relaxed SHOULD use e.g. schema.org or FOAF, and WebID-Profile-Bar-strict-classic MUST use FOAF?

(preferably explained in simple words - sorry, I am not fluent in the lingo of logic)

[jonassmedegaard]

What I am trying to emphasize with my followup question above is to elaborate further on what I understand as a loose coupling between WebID (not mandating any semantics), and each WebID-Profile-* spec which may or may not mandate various constraints suitable to ensure whateer each of them aim for.

[kidehen]

Why would WebID-Lib developer be tickled by our choice to specify that WebID-Profile-Foo-easy-peasy MUST use schema.org, WebID-Profile-Bar-relaxed SHOULD use e.g. schema.org or FOAF, and WebID-Profile-Bar-strict-classic MUST use FOAF?

Assumption that needs to qualify my reply: A 'Web Developer' would be the one creating the library, and they have little interest in things perceived as being RDF-based (despite all the irony inherent in that perspective).

The problem with RDF, and by effect FOAF, is that they have image issues outside the Semantic Web community. None of this is necessarily deserved, but that (unfortunately) is the state of play -- in my experience.

This is why I strongly encourage emulating how other initiatives (e.g., Schema.org, ActivityPub, and ActivityStreams) have worked around these issues, successfully.

We've been at this matter for some 14 years now, and progress has been limited, for all the wrong reasons -- IMHO.

[kidehen]

What I am trying to emphasize with my followup question above is to elaborate further on what I understand as a loose coupling between WebID (not mandating any semantics), and each WebID-Profile-* spec which may or may not mandate various constraints suitable to ensure whateer each of them aim for.

I think the following could help regarding the loose-coupling that needs to underlie this entire effort:

1. TimBL's original meme titled "Give yourself a URI" -- "WebID" (as I know it) was coined with the aim of compressing the notion of a Personal URI into something more palatable to the everyday Web User
2. Late Henry's worldview about WebID in relation to OpenID -- he always conflated WebID, WebID-Profile, and WebID-TLS (and never relinquished that position in the spec he oversaw)

Earlier today, @melvincarvalho reiterated an underlying way forward, which I strongly believe is achievable -- with some flexibility and focus.

I hope these matters are clearer? Basically, we need to properly specify the following in a manner that reflects their loosely-coupled nature:

1. WebID -- this is piece of the broader operating environment (an HTTP-based Network)
2. WebID Profile Document -- specifies how different components (agent naming and vocabulary terms) are used to describe one or more profile subjects
3. WebID-{Whatever-Auth-Protocol} -- how identity authenticity is achieved by processing WebID-Profile doc content

[melvincarvalho]

Earlier today, @melvincarvalho reiterated an underlying way forward, which I strongly believe is achievable -- with some flexibility and focus.

It's good to focus on what we agree on. I think we are developing an increasing common ground. Also some good news here. Solid appears to have merged a commit on the equivalence of forward and reverse properties, baby steps towards convergence perhaps:

https://github.com/solid/webid-profile/commit/a1c2792e4d998daea22c98e2c84e053d636a1953

A profile can be compiled by reading all statements with the WebID as the subject or the object, regardless of their originating documents

I had suggested it previously in their chat, and I'm delighted that there had been progress

I think we just need to make schema and foaf loosely or strongly equivalent, and we're almost home

[TallTed]

I think we just need to make schema and foaf loosely or strongly equivalent, and we're almost home

Well, the schema.org ontology is MUCH bigger than the FOAF ontology, so I think you have to focus on a few specific elements of these.

Making explicit the similarity (very rarely strong equivalence) between/among pairs/groups of terms like foaf:primaryTopic and schema:mainEntity is fairly easy IF you require some Inference/Reasoning by adding a "connecting" dataset/ontology, which is primarily built with SKOS, OWL 1, and OWL 2 predicates, including but not limited to skos:exactMatch, owl:equivalentProperty, owl:equivalentClass, and even owl:sameAs. (It is usually best to limit use of owl:sameAs, which indicates that the subject and object URIs refer to the same entity, i.e., it indicates coreference. It is an appropriate predicate to use between, for instance, two WebIDs that identify the same person.)

That "ease" given, people do tend to be reluctant to rely on inference/reasoning, because it is perceived as a query performance killer. Whether this perception is accurate depends on the dataset in question, the query processor implementation, the actual queries being run, and many other variables. The most common response is to say, "just materialize all the inferences," but that tends to concretize things which were designed to be flexible. We should not try to force the world to consider, for instance, skos:exactMatch and owl:sameAs to be owl:sameAs each other, for all time, past, present and future -- though it might be appropriate to treat them as such when dealing with a graph with known content (as opposed to a graph composed on the fly from random/arbitrary sources).

Flexibility is good, it enables lots of unplanned possibilities. Flexibility it bad, it requires handling lots of possibilities. Flexibility is a two-edged sword. Q.E.D.

[webr3]

people do tend to be reluctant to rely on inference/reasoning

Yes, however this can be a totally moot point if a property such as :publickey with domain Agent exists.

There seems to be a focus on a single property here to sniff, if you want to be explicit set the type, if not then any one of an infinite set of properties can be created to handle this, and the most commonly required by use cases are probably the ones to lean on or create if missing.

Any property known to have the correct domain or range can be used, and to avoid reasoning having a common one utilized in some part of auth* likely provides what's needed for those critical ifs.

Again, forcing a 1:1 and archaic approaches for a web-scale identity solution is probably not the most inclusive, or useful, thing to do.

[jacoscaz]

Closed by #60 but let's open a new issue if, at any point, we want to discuss and re-introduce backward predicates.