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

[acoburn]

I checked in FOAF and the latter does not exist.

A point of clarification: the foaf website is using an old version. See, for instance:

ALERT! We are currently serving an older version of the FOAF spec, from 2004, while restoring from archives. Although it did not change radically between 2004 and 2014 (last release), please consult the Internet archive ( html, rdf) for that and earlier releases, which extend back to our earliest version in 2000.

If you fetch the RDF from the 2014 version of the site, you will, in fact, find the foaf:isPrimaryTopicOf predicate definition.

Also, note that the property includes an is in the name: isPrimaryTopicOf, so the question should really be between :primaryTopic and :isPrimaryTopicOf.

[melvincarvalho]

Thanks @acoburn topic changed to isPrimaryTopicOf

Note also: mainEntityOfPage

https://schema.org/mainEntityOfPage

I think it makes sense from my POV to go with these reverse relations to start off with, and also include versioning

The question is where that leaves solid which I think still uses the primaryTopic.

@acoburn do you have a preference here, would the rev relation be too big a change, do you think? Perhaps this is just a question for non-normative examples, which are still quite important, since developers will use copy and paste alot.

[melvincarvalho]

<script type="application/ld+json">
{
    "@context": "https://schema.org",
      "@type": "Restaurant",
      "mainEntityOfPage": "http://cathscafe.example.com/",
      "name": "Cath's Cafe",
      "openingHours": "Mo,Tu,We,Th,Fr,Sa,Su 11:00-20:00",
      "telephone": "+155501003344",
      "hasMenu": "/menu"
}
</script>

Reproducing the example from schema, you could modify it to be:

<script type="application/ld+json">
{
    "@context": "https://schema.org",
      "@type": "Person",
      "mainEntityOfPage": "http://cath.example.com/",
      "name": "Cath",
      "telephone": "+155501003344"
}
</script>

Perhaps this should be the canonical WebID 1.0 example. Simple. Easy. Anyone can do it.

I wonder if @danbri has a view...

[danbri]

Sounds plausible!

On Tue, 5 Dec 2023 at 09:35, Melvin Carvalho @.***> wrote:

Reproducing the example from schema, you could modify it to be:

Perhaps this should be the canonical WebID 1.0 example. Simple. Easy. Anyone can do it.

I wonder if @danbri https://github.com/danbri has a view...

— Reply to this email directly, view it on GitHub https://github.com/w3c/WebID/issues/24#issuecomment-1840379737, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGPADRSQ3HORU7GE2NDYH3TFHAVCNFSM6AAAAABAGGKS2WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBQGM3TSNZTG4 . You are receiving this because you were mentioned.Message ID: @.***>

[TallTed]

@melvincarvalho — Please make your edits as Pull Requests, rather than direct Commits, so that we can collaboratively edit the text toward (optimally) a single PR (and Commit) per issue, which will keep the commit history clean, and retain a record of contributions by multiple people.

Also, because the changes in the commit you've made do not appear to be about primaryTopic vs isPrimaryTopicOf, and do not incorporate the discussion above ... making me quite confused.

[melvincarvalho]

Thank you, @TallTed for the suggestion. Currently, Solid lite is a completely new draft, and in its initial 0.0.1 phase, evolving independently until a stable version is achieved. Our goal is to craft a spec with wide appeal among web developers, akin to the approach of schema.org. We're focusing on real-world applications and practicality, similar to how downstream projects are experimenting with WebID drafts to find effective solutions.

Our priority is working templates and running code, particularly in areas that greatly simplify deployment and encourage broad interoperability. We are looking forward to demonstrating this through running code and practical demos, and I encourage the CG and WebID adopters to consider this streamlined approach to WebID.

Let’s continue our focus on the topic of including 'primaryTopic' vs 'isPrimaryTopicOf', and the later discovery of mainEntityOfPage, as we aim for a modernization of the WebID specs. Hopefully these patterns will all align once the CG reaches consensus of WebID 1.0.

[jacoscaz]

I think @woutermont made an excellent point here: https://github.com/w3c/WebID/issues/23#issuecomment-1826233591 .

From a discovery point of view, a WebID Profile Document is just another Web Resource. Let's not throw REST out the door without good reasons, and have a WebID Profile Document at least state what it is or is about. Not only does this improve its semantics (and therefore human and machine understanding of it), but it also allows us to perform the simple validation after dereferencing that we actually retrieved a WebID Profile Document about the WebID we dereferenced, and not (by human or machine error) some other random Web Resource. [...] I believe the most crucial statement is the one linking the document to the agent: <> foaf:primaryTopic <...webid...> .

[woutermont]

@jacoscaz, thanks for the reference, but the main point I wanted to make is that at least one such link has to be included. What form that link takes (FOAF vs Schema.org; forward or backward predicate) is less relevant i.m.o.

---

If I had to add my two cents:

• Prefer FOAF over Schema.org, since the latter has always had a rather dubious relationship to RDF.
• Prefer forward predicate (foaf:primaryTopic) over backward one (foaf:isPrimaryTopicOf), because it has been in use for ten years longer.
• Prefer foaf:primaryTopic overall, because of typical current usage.

[jacoscaz]

@woutermont apologies for reading too much into your words, I somehow inferred part of these additional "two cents" points from within your other comment. I suspect this is a classic case of looking for one's own set of biases.

Evidently, then, I fully agree with your additional points! Backward compatibility has also been recently raised by @namedgraph in https://lists.w3.org/Archives/Public/public-webid/2023Dec/0009.html . +1 from me to foaf:primaryTopic.

[jacoscaz]

@namedgraph @kidehen @webr3 @jonassmedegaard ?

[namedgraph]

I don't understand the relation of the topic of this thread to its first message.

Is this about the JSON-LD context or what triple patterns the WebID Profile Document should match?

Re. the context, I think both foaf:primarTopic and foaf:isPrimaryTopicOf should be included as they are inverse properties if I recall correctly. Also foaf:title property does not exist.

As for the triple patterns, they are defined in the WebID-TLS' Verifying the WebID Claim With SPARQL. I don't think we should mandate more metadata than required by the queries. Agent name etc. are nice to have but not essential, potential SHOULD but not MUST.

[melvincarvalho]

@namedgraph implementers may wish to choose a predicate which relates a WebID to the Identity Document.

Perhaps different folks will prefer different predicates. In this thread the schema:mainEntityOfPage was discovered as an option.

Benefits:

• it is very easy to implement
• it avoids nested objects
• it comes from a well maintained, well documented, vocab with broad adotoption

IMHO it offers a great simplification for WebID. It is simple, it is interoperable, and it has a chance of broad deployment (as schema is already widely deployed)

It's up to the CG to reach a consensus on this, or not. But for me schema:mainEntityOfPage is a clear winner, and what I will personally implement.

[namedgraph]

@melvincarvalho I understand but it's still just nice to have IMO. If the WebID has a hash URI, the client can find the agent's resource in the dereferenced graph even without any predicate connecting them (the resource and the graph/document).

Mandating a schema.org predicate would break compatibility for pretty much all existing WebID profile documents.

[kidehen]

Why are FOAF terms being used as the basis for creating WebID Profile Document content, when Schema.org has long superseded it?

FOAF isn't broadly adopted.

Schema.org offers terms such as schema:mainEntity and schema:mainEntityOfPage that are broadly adopted for what the WebID spec is trying to formalize.

[jonassmedegaard]

I disagree that FOAF is not broadly adopted. Not hard numbers but a simple visualization that seems to support my view: https://lov.linkeddata.es/dataset/lov/

In case "thumbs up" does not count in this conversation, let me also mention explicitly: I fully agree with https://github.com/w3c/WebID/issues/24#issuecomment-1849006471

[namedgraph]

FOAF isn't broadly adopted.

Are you serious? :) It's probably in the top 3 of most widely used vocabularies: https://lov.linkeddata.es/dataset/lov/

[kidehen]

I disagree that FOAF is not broadly adopted. Not hard numbers but a simple visualization that seems to support my view: https://lov.linkeddata.es/dataset/lov/

In case "thumbs up" does not count in this conversation, let me also mention explicitly: I fully agree with #24 (comment)

Additional context for my comment:

FOAF is used across the litany of pages that already function as profile pages on the Web today; especially with regards to the developer profile (not RDF savvy or interested) required to take WebID mainstream.

There are tons of FOAF docs from the Semantic Web community out on the Web, but I don't believe that's the audience for taking WebID mainstream. Moreover, a SemanticWeb aficionado will easily handle the required ontological mapping between FOAF and Schema.org terms.

I use FOAF and Schema.org terms in my example profile doc to demonstrate this point.

[kidehen]

FOAF isn't broadly adopted.

Are you serious? :) It's probably in the top 3 of most widely used vocabularies: https://lov.linkeddata.es/dataset/lov/

See my latest response for context. And yes, I am serious.

[danbri]

We'll get FOAF fixed up all modern, and maybe aligned here and there with Schema. Beyond that - I think it is important not to make the mistake that such a choice of namespace is the main thing holding webid back from mass adoption. What kinds of identity providers are you pursuing, do they have any written requirements we can look at?

[jacoscaz]

@danbri that's a very fair point but I don't think anyone is under the illusion that the choice of namespace is what's holding WebID back (as least I hope!). But, choosing one would definitely help getting to WebID 1.0, which, in turn, would definitely help in that regard (IMHO). Very good to hear that work on FOAF is ongoing! Do you have a timeline for that? No pressure meant or implied, just curious.

[kidehen]

I think it is important not to make the mistake that such a choice of namespace is the main thing holding webid back from mass adoption.

To be clearer about my point regarding adoption and target audience.

Target Audience

Web Developers, not Semantic Web aficionados.

What's already out in the wild, by target audience

Lots of profile documents that describe a Person or Organization. These are heavily influenced by Google's support for Schema.org, and the promise of smarter SEO etc..

Example of a Blog Post showcasing what I mean

https://blogs.microsoft.com/blog/2023/11/02/new-study-validates-the-business-value-and-opportunity-of-ai/

JSON-LD Embedded:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://blogs.microsoft.com/blog/2023/11/02/new-study-validates-the-business-value-and-opportunity-of-ai/",
      "url": "https://blogs.microsoft.com/blog/2023/11/02/new-study-validates-the-business-value-and-opportunity-of-ai/",
      "name": "New study validates the business value and opportunity of AI - The Official Microsoft Blog",
      "isPartOf": {
        "@id": "https://blogs.microsoft.com/#website"
      },
      "primaryImageOfPage": {
        "@id": "https://blogs.microsoft.com/blog/2023/11/02/new-study-validates-the-business-value-and-opportunity-of-ai/#primaryimage"
      },
      "image": {
        "@id": "https://blogs.microsoft.com/blog/2023/11/02/new-study-validates-the-business-value-and-opportunity-of-ai/#primaryimage"
      },
      "thumbnailUrl": "https://blogs.microsoft.com/wp-content/uploads/prod/2023/11/294139_MS_Blog.jpg",
      "datePublished": "2023-11-02T14:59:59+00:00",
      "dateModified": "2023-11-08T00:35:58+00:00",
      "author": {
        "@id": "https://blogs.microsoft.com/#/schema/person/0ee4146694a76ebe09c792c67dbb9b62"
      },
      "breadcrumb": {
        "@id": "https://blogs.microsoft.com/blog/2023/11/02/new-study-validates-the-business-value-and-opportunity-of-ai/#breadcrumb"
      },
      "inLanguage": "en-US",
      "potentialAction": [
        {
          "@type": "ReadAction",
          "target": [
            "https://blogs.microsoft.com/blog/2023/11/02/new-study-validates-the-business-value-and-opportunity-of-ai/"
          ]
        }
      ]
    },
    {
      "@type": "ImageObject",
      "inLanguage": "en-US",
      "@id": "https://blogs.microsoft.com/blog/2023/11/02/new-study-validates-the-business-value-and-opportunity-of-ai/#primaryimage",
      "url": "https://blogs.microsoft.com/wp-content/uploads/prod/2023/11/294139_MS_Blog.jpg",
      "contentUrl": "https://blogs.microsoft.com/wp-content/uploads/prod/2023/11/294139_MS_Blog.jpg",
      "width": 960,
      "height": 540,
      "caption": "Illustration showing points representing information"
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://blogs.microsoft.com/blog/2023/11/02/new-study-validates-the-business-value-and-opportunity-of-ai/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Home",
          "item": "https://blogs.microsoft.com/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "New study validates the business value and opportunity of AI"
        }
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://blogs.microsoft.com/#website",
      "url": "https://blogs.microsoft.com/",
      "name": "The Official Microsoft Blog",
      "description": "",
      "potentialAction": [
        {
          "@type": "SearchAction",
          "target": {
            "@type": "EntryPoint",
            "urlTemplate": "https://blogs.microsoft.com/?s={search_term_string}"
          },
          "query-input": "required name=search_term_string"
        }
      ],
      "inLanguage": "en-US"
    },
    {
      "@type": "Person",
      "@id": "https://blogs.microsoft.com/#/schema/person/0ee4146694a76ebe09c792c67dbb9b62",
      "name": "Alysa Taylor",
      "url": "https://blogs.microsoft.com/blog/author/ataylor/"
    }
  ]
} 

To reiterate my fundamental point: We need to meet "Web Developers" where they're at i.e., they are already publishing profile docs in HTML comprising JSON-LD structured data islands. These islands are using Schema.org terms, not FOAF.

A Semantic Web aficionado that seeks FOAF, can easily integrate it at the ontology level without unleashing what would be seen as impedance by the target "Web Developer" audience (ie., folks who don't care at all about RDF or FOAF).

[jacoscaz]

It seems to me like we're collectively looking at this through different perspectives:

• On one side, backward compatibility concerns lead to foaf:primaryTopic
• On the other side, future-proofing and opening up to non-RDF devs lead to schema:mainEntity

Now, these two are not necessarily mutually exclusive. After all, we're discussing about the minimum set of statements to qualify an identity document as such (again, lowercase as the precise name for the document associated to a webid is not within the scope of this specific discussion).

Would it be ok to have the spec require at least one between foaf:primaryTopic and schema:mainEntity ?

[kidehen]

Would it be ok to have the spec require at least one between foaf:primaryTopic and schema:mainEntity ?

Yes, in an ideal world. In the world as it currently exists, Semantic Web aficionados are capable of implementing mappings that handle the underlying semantics of either property. However, this isn't the case for 'Web Developers', which is why I discourage mandating FOAF terms.

We have to meet 'Web Developers' where they are, should we seek to engage and bootstrap successfully.

[jonassmedegaard]

choosing [namespace] would definitely help getting to WebID 1.0

It the aim of this discussion to a) decide on a term to use in a default example, or b) to mandate a term that must be used in the RDF graph served at the endpoint resolved by an IRI for that IRI to legally be called a WebID?

To me it is definitely helpful to do a), and I can see a point in pleasing web developers by using the more sloppy schema.org ontology for such default example.

As for b), I would however not say that it definitely is helpful to mandate a specific term to use explicitly in the graph. I am concerned that the aim of schema.org is mainly SEO. What is important for WebID functionality is that the RDF graph can hook into mechanisms for authentication - simplicity of use for web developers is of less importance here. Possibly schema:mainEntityOfPage is perfectly fine for any and all authentication mechanisms, and possibly foaf:primaryTopic is perfectly fine as well. But I would prefer that we only RECOMMEND to use either of those, and leave it to standard RDF reasoning rules to declare loose or strict semantics as each authontication mechanisms see fit.

[jonassmedegaard]

I find relevant the related concerns raised here: https://ec-jrc.github.io/dcat-ap-to-schema-org/#alignment-issues

the main purpose of Schema.org is to enhance discovery and indexing of online resources via search engines. As such, it is addressing more general objectives compared with DCAT-AP, that is instead meant to represent in detail information on datasets and data catalogues.

One of the main consequences is that some information that is relevant in DCAT-AP it is not described in Schema.org with specific terms. This results in a relevant amount of (a) "missing" and (b) "many-to-one" mappings - i.e., different metadata elements of DCAT-AP are mapped to the same element in Schema.org.

This is not necessarily a problem, since the objective of mapping DCAT-AP and Schema.org is to enhance discoverability of DCAT-AP metadata on the Web, which does not require a complete, 1-to-1 representation of DCAT-AP metadata. Actually, the result of this exercise can also include the identification of the subset of DCAT-AP metadata elements that is worth representing in a Schema.org-based description. On the other hand, this situation also implies that a reverse mapping (i.e., from Schema.org to DCAT-AP) may be problematic or not possible

[kidehen]

I am concerned that the aim of schema.org is mainly SEO. What is important for WebID functionality is that the RDF graph can hook into mechanisms for authentication - simplicity of use for web developers is of less importance here.

Something has to give re semantic sloppiness vs precision. As I've indicated in my prior comments, Semantic Web aficionados are the ones that possess the skillset necessary for handling a little burden re property mappings across Schema.org and FOAF. A 'Web Developer' will never undertake those steps.

It is my hope that WebID is broadly used for unambiguous agent naming while also providing critical foundation for broadly adopted authentication protocols.

RDF and 'Web Developers' is like Chalk & Cheese, hence my suggestions regarding Schema.org.

[kidehen]

Possibly schema:mainEntityOfPage is perfectly fine for any and all authentication mechanisms, and possibly foaf:primaryTopic is perfectly fine as well. But I would prefer that we only RECOMMEND to use either of those, and leave it to standard RDF reasoning rules to declare loose or strict semantics as each authontication mechanisms see fit.

That works, since we are saying similar things in slightly different ways.

[jacoscaz]

It the aim of this discussion to a) decide on a term to use in a default example, or b) to mandate a term that must be used in the RDF graph served at the endpoint resolved by an IRI for that IRI to legally be called a WebID?

Let me try to break down all the different dimensions of this issue that we've touched upon:

1. priorities: backward compatibility vs. catering for non-RDF devs
2. vocab: foaf vs. schema
3. predicate directionality: foaf:primaryTopic vs. foaf:primaryTopicOf and schema:mainEntity vs. schema:mainEntityOfPage
4. whether the use of any given predicate should be recommended or mandatory: SHOULD vs. MUST

It feels to me, also looking at other threads of discussion that touched upon these topics (see @woutermont 's comment https://github.com/w3c/WebID/issues/23#issuecomment-1826233591, for example), that the strongest consensus is to be found in recommending the use of either of foaf:primaryTopic and schema:mainEntity.

Does anyone believe this compromise to be an absolute no-go?

@namedgraph @melvincarvalho @acoburn @jonassmedegaard @kidehen @TallTed @woutermont

[jonassmedegaard]

the strongest consensus is to be found in recommending the use of either of foaf:primaryTopic and schema:mainEntity.

I agree with the above.

I think it would be helpful to explicitly add a passage in the core WebID spec that clarifies that other authentication specs MAY impose constraints but this core spec does not. To aid in getting that flexibility across, I think it would be helpful to provide two examples, one using schema.org and one using foaf. But if consensus cannot be reached on that, I can (reluctantly) agree with using only schema:mainEntity for a single set of examples.

[kidehen]

I think it would be helpful to provide two examples, one using schema.org and one using foaf.

Maybe 3 examples i.e., adding one that integrates both -- which would be a subtle reminder to RDF aficionados of its ontology level cross-referencing capabilities aimed at reasoning and inference. As one would expect, understandably, this example will be of little or no interest to typical 'Web Developers' .

[melvincarvalho]

schema:mainEntityOfPage for me, for reasons stated above.

[TallTed]

I think it would be helpful to provide two examples, one using schema.org and one using foaf.

Maybe 3 examples i.e., adding one that integrates both

The above captures my earlier-conceived revision of --

recommending the use of either of foaf:primaryTopic and schema:mainEntity

-- to --

recommend the use of either if not both foaf:primaryTopic and schema:mainEntity

It is worth remembering that the WebID concept grew from the foaf+ssl project, and recognizing that there remain millions of user-focused web pages (LiveJournal alone delivers this via https://{exampleusername}.livejournal.com/data/foaf.rdf) that include foaf-based descriptions, hence being known as "FOAF files" (primarily based on FOAF-defined predicates/properties/attributes), a precursor of today's "WebID Profile Documents" (possibly starting from FOAF-defined predicates/properties/attributes, but including predicates/properties/attributes from any number of other vocabularies/ontologies).

[jacoscaz]

recommend the use of either if not both foaf:primaryTopic and schema:mainEntity

Works for me!

[woutermont]

@jacoscaz, I'll be a pain in the ass, but I'm afraid I strongly disagree. I'll try to address the 4 dimensions you listed below.

[@jonassmedegaard:] It the aim of this discussion to a) decide on a term to use in a default example, or b) to mandate a term that must be used in the RDF graph served at the endpoint resolved by an IRI for that IRI to legally be called a WebID?

Definitely (b), because we need a required link (a MUST) between the WebID Document and the Agent it is about (see above).

The FOAF vs Schema.org discussion makes no sense. Apart from the fact that Schema.org is not a valid and consistent RDF vocabulary, the point here is not to decide WHICH predicate we want to use, but whether or not we want to remain backwards compatible.

• If we do care about backwards compatibility, there is only one choice: foaf:primaryTopic.

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

In any case, picking more than one simply does not make sense (except perhaps for the syntactic sugar of an inverse): if the spec prescribes a certain predicate, WebID Documents will have to contain it. It's not rocket sience; anyone who can copy-paste can do it. If people want to say more than "this is a WebID Document about that Agent," they can just as easily add an extra line with whatever other predicate they want.

As an aside: giving a choice between multiple options with unaligned semantics also indicates to the world how little we actually care about semantics.

[jacoscaz]

@woutermont no pain at all. On the contrary, I find your feedback to always be excellent - regardless of whether I agree or not. Incidentally, I also happen to personally agree. In light of Dan's feedback on the state of foaf, my preferred option would be to mandate foaf:primaryTopic. Note to self: I need to be more explicit in indicating whether I'm speaking as the group's chair or as myself.

As an aside: giving a choice between multiple options with unaligned semantics also indicates to the world how little we actually care about semantics.

Could you elaborate on this? This is an important consideration but foaf:primaryTopic and schema:mainEntity seem roughly equivalent to me. Inferring one from the other wouldn't seem that much of a stretch, for example.

To everyone: could you indicate both which of the following options would be your favorite and which of the following options you absolutely could not live with?

1. foaf:primaryTopic
2. schema:mainEntity (breaks backward compatibility)
3. at least one between schema:mainEntity and foaf:primaryTopic (breaks backward compatibility)
4. both schema:mainEntity and foaf:primaryTopic

@namedgraph @melvincarvalho @acoburn @jonassmedegaard @kidehen @TallTed @woutermont

[jonassmedegaard]

Favorite: 1 ~Unbearable~ Unacceptable: 2 or 4

( don't think anyone has actually proposed option 4)

[jacoscaz]

Thank you @jonassmedegaard , excellent feedback and I like the format. For me: Favorite: 1 Unbearable: 2

[danbri]

I don’t think “unbearable” means what you seem to think it means

On Sat, 30 Dec 2023 at 16:26, Jacopo Scazzosi @.***> wrote:

Thank you @jonassmedegaard https://github.com/jonassmedegaard , excellent feedback and I like the format. For me: Favorite: 1 Unbearable: 2

— Reply to this email directly, view it on GitHub https://github.com/w3c/WebID/issues/24#issuecomment-1872559533, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGMFL6I4CKCZIO7EMBTYMA6EDAVCNFSM6AAAAABAGGKS2WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSGU2TSNJTGM . You are receiving this because you were mentioned.Message ID: @.***>

[jonassmedegaard]

Thank you, @danbri - today I learned :-)

[kidehen]

To everyone: could you indicate both which of the following options would be your favorite and which of the following options you absolutely could not live with?

1. foaf:primaryTopic
2. schema:mainEntity (breaks backward compatibility)
3. at least one between schema:mainEntity and foaf:primaryTopic (breaks backward compatibility)
4. both schema:mainEntity and foaf:primaryTopic

I would encourage a little more context regarding these options. For example:

Item 1: To be clear, this attribute offers backward compatibility to existing implementations of the WebID-TLS protocol, solely. Again, this brings up the core problem with the current spec where Identity, Identification, and Authentication (i.e., WebID-TLS protocol) are conflated.

Item 2: A forward-looking attribute, already widely used, that effectively separates Identity, Identification, and Authentication. This loose-coupling is essential for future-proofing the system, and it would be beneficial to provide specific examples or case studies to illustrate its practical application.

Item 3: This choice fails the "Wisdom of Solomon" test, offering a stark, life-or-death decision for WebID in its current, ambiguously defined form. Adopting foaf:primaryTopic is unlikely to foster broader adoption, only catering to a small, stagnant pool of implementations. Our implementation at OpenLink Software, in all its variations, underlines this perspective, informed by real-world application and observation.

Item 4: This option successfully passes the "Wisdom of Solomon" test. It not only ensures backward compatibility for WebID but also opens avenues for widespread adoption among web developers, who might typically shy away from the perceived complexities of RDF. This approach strikes a balance between maintaining legacy systems and appealing to new, broader audiences.

Conclusively, given the considerations above, I favor Item 4. I consistently support the approach of loosely coupling identity, identification, authentication, authorization, and storage, focusing on achieving wide-scale adoption and practical utility.

[jonassmedegaard]

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

I am unaware that FOAF is about authentication at all.

Or do you perhaps simply mean that the first reminds you of an era where they were commonly conflated, whereas the latter does not?

[danbri]

foaf:primaryTopic and schema:mainEntity mean the same thing. I can put that in both schema definitions if it would be helpful.

On Sat, 30 Dec 2023 at 19:50, Jonas Smedegaard @.***> wrote:

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

I am unaware that FOAF is about authentication at all.

Or do you perhaps simply mean that the first reminds you of an era where they were commonly conflated, whereas the latter does not?

— Reply to this email directly, view it on GitHub https://github.com/w3c/WebID/issues/24#issuecomment-1872592695, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGIBQPND6U3UVH6MRBDYMBWADAVCNFSM6AAAAABAGGKS2WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSGU4TENRZGU . You are receiving this because you were mentioned.Message ID: @.***>

[woutermont]

• Preference if backward compatibility is important: foaf:primaryTopic.
• Preference if not (which should be added as an option): a new predicate in the WebID namespace.
• Unacceptable: schema:mainEntity and any combination with it.

[woutermont]

[@woutermont:] [G]iving a choice between multiple options with unaligned semantics also indicates to the world how little we actually care about semantics.

[@jacoscaz:] Could you elaborate on this? This is an important consideration but foaf:primaryTopic and schema:mainEntity seem roughly equivalent to me. Inferring one from the other wouldn't seem that much of a stretch, for example.

First of all "roughly" the same semantics is no good when writing specs (or anything semantics related really). And honestly, I would say these aren't even roughly the same at all. I elaborate below.

[@danbri:] foaf:primaryTopic and schema:mainEntity mean the same thing. I can put that in both schema definitions if it would be helpful.

This is definitely not the case now, and making it so is not trivial, and will be a breaking change for existing use of those predicates.

• foaf:primaryTopic relates a foaf:Document to an owl:Thing.
• schema:mainEntity relates a schema:CreativeWork to a schema:Thing.

While it can be (and has been) argued that owl:Thing and schema:Thing are equivalent, they are not by definition, they aren't even similar from a language design perspective, and a number of existing vocabularies treat the latter as an rdfs:subClassOf the former. Even if we ignore this, foaf:Document and schema:creativeWork are obviously at most partially overlapping classes, not equivalent ones.

All this is even more heavily troubled by the fact that the semantic foundations of Schema.org make no sense.^ It is a pain in the eye of many developers and researchers, and the only reason it is being used is its popularity amongst people who don't really know (or care) about semantics, which is sadly but understandably the majority of people.

---

^ Because I guess this will get some reaction, I will give an example applied to schema:mainEntity. In its definition, we find that it has an inverse property called schema:mainEntityOfPage, the range of which includes not only the class schema:CreativeWork, but also the class schema:URL, which is defined as a data type and a subclass of schema:Text. Without even going into the difficulties of having data types be a classes (which breaks with RDF), this leads to the following useless semantics of schema:mainEntityOfPage (and therefore also its inverse schema:mainEntity): they relate the some main entity to some creative work OR to some URL! Read this again carefully: a creative work can have a main entity, and an URL can have a main entity; not the page to which the URL resolves, but the URL itself, i.e. a character sequence! After all, the class schema:URL is defined as a data type, as a subclass of schema:Text. And this is just one of many similar artefacts of carelessness in Schema.org. QED

[jacoscaz]

Chair hat on...

Thank you @kidehen and @woutermont for taking the time to elaborate - much appreciate and instructive.

So far option 1, which is foaf:primaryTopic, seems to be the group's favorite while not being fully unpalatable to anyone.

[kidehen]

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.

[kidehen]

All this is even more heavily troubled by the fact that the semantic foundations of Schema.org make no sense.^

Schema.org has issues, from the vantage point of Semantic Web aficionados. These issues don't mean much to "Web Developers" in the slightest.

Thus, we have to answer a simple question regarding this spec: Who is it for? The "Web Developer" or the "Semantic Web Aficionado" ? If we have a modicum of interest in the former, then we have to live with schema.org's so-called imperfections.

Note, schema.org's imperfections, in the eyes of "Semantic Web Aficionados" exist for the very same "Web Developer" engagement reasons I am constantly trying to bring to the fore via comments.

From my vantage point: Schema.org is a phenomenal success that's actually helped the move toward the notion of a Semantic Web.

I invoke the "Wisdom of Solomon" repeatedly because it's a timeless demonstration of the value of compromise aimed at enabling a greater good :)

[kidehen]

So far option 1, which is foaf:primaryTopic, seems to be the group's favorite while not being fully unpalatable to anyone.

Only if this group doesn't care in the slightest about "Web Developer" engagement.

There's simple questions to be answered right now, regarding who this spec is for?

1. Is it for Semantic Web Aficionados?
2. Is it for Web Developers?
3. Is it for either?

[jonassmedegaard]

Who is it for? The "Web Developer" or the "Semantic Web Aficionado" ? If we have a modicum of interest in the former, then we have to live with schema.org's so-called imperfections.

Do we really?

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!

[woutermont]

Most web developers don't care about the details of HTTP either, but the fact that it has a consistent semantics is precisely what makes it work. Most web developers' lack of care for semantics is also what made HTML be a jungle of misused tags that no computer can understand. Most web developers disregard for theory in general is what led to the need for the ridicilously complex WHATWG URL standard to cope with the historical misuse of URIs...

Most web developers are hackers: they have a problem, they see what's available for them to solve it, and as long as their solution works within the limited context of that problem, they are happy. I would hope that in the development of standards, we strive for higher aims than that.

This all goes to show that

• if we start by following the low standards of "most web developers", we might as well not start, since they will find a solution for their problems either way;
• even if we strive for higher standards, web developers will have no problem to work with the result;
• even if we strive for higher standards, web developers will no doubt misuse the result anyway.