primaryTopic vs isPrimaryTopicOf

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

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.

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.

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

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

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.

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

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

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

@namedgraph @kidehen @webr3 @jonassmedegaard ?

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.

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

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

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.

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

FOAF isn't broadly adopted.

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

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.

@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 IMHO would definitely help in that regard. Very good to hear that work on FOAF is ongoing! Do you have a timeline for that? No pressure meant or implied, just curious.

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

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 ?

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.

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.
I would 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.

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

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.

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.

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:

priorities: backward compatibility vs. catering for non-RDF devs
vocab: foaf vs. schema
predicate directionality: foaf:primaryTopic vs. foaf:primaryTopicOf and schema:mainEntity vs. schema:mainEntityOfPage
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

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.

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, this item, understandably, will be of little or no interest to typical 'Web Developers' .

schema:mainEntityOfPage for me, for reasons stated above.

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

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

Works for me!

[@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 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.

@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?

foaf:primaryTopic
schema:mainEntity (breaks backward compatibility)
at least one between schema:mainEntity and foaf:primaryTopic (breaks backward compatibility)
both schema:mainEntity and foaf:primaryTopic

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

Favorite: 1
Unbearable: 2 or 4
( don't think anyone has actually proposed option 4)

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

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

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?

foaf:primaryTopic
schema:mainEntity (breaks backward compatibility)
at least one between schema:mainEntity and foaf:primaryTopic (breaks backward compatibility)
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.

@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?

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:] [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

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.

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.

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 :)

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?

Is it for Semantic Web Aficionados?
Is it for Web Developers?
Is it for either?

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!

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.

Schema.org is a phenomenal success

Indeed, schema has massive adoption.  WebID currently has relatively little adoption.  By aligning with schema, it goes 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.

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.

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.

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?

Fediverse
Web Pages comprising enhanced metadata

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

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.

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.

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.

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 :)

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.

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.

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

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)?

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 as an SEO tool.  It's the single most important vector in bringing the semantic web into the mainstream.

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:

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

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?

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.

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.

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.

[@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.

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 presumptions associated with machine-computability of what constitutes and agent.
My position is that said machine-computability isn't required i.e., that spec explains that in prose.
Attributes and Classes only come into play with regards to profile docs and authentication protocols related specifications.

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

Years ago, when Linked Data principles and the LOD Cloud where taking shape, there where 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.
Back then, as it does right now re WebID, it occurred to me that specifying the document that depends on an HTTP URI is much easier than starting from the HTTP URI itself.
For example:
Describing the nature of http://dbpedia.org/page/Linked_Data is much easier starting point for specification than http://dbpedia.org/resource/Linked_Data.
Describing and specifying a WebID-Profile Document is much easier that specifying a WebID, which is one amongst other important and loosely-coupled components.

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.

Solution routes:

Fix the title of the current doc, since "WebID and Identity Discovery (WebID)" is utterly broken
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?

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.

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.

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

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.

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?  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. 🤷♂

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

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

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:

Identity -- facilitated by an identifier serving the needs of "denotation"
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 :)

To clarify:

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

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

Identity: a set of characteristics of an entity that uniquely determines that identity (e.g. any resource, including agents)
Identifier: a minimal identity (e.g. any URI, including WebIDs)
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 😄

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.

That's the identity relation, which is another thing.  But let's have this talk somewhere else (perhaps in real life someday) ...

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)

What I am trying to emphasize with my followup question above is wht 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.

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.

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:

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
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 specifying the following in a manner that reflects their loosely-coupled nature:

WebID
WebID Profile Document -- the most important doc, as I see it
WebID-{Whatever-Auth-Protocol}

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 progress
I think we just need to make schema and foaf loosely or strongly equivalent, and we're almost home

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.

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


Apply existing device processing logic for device registration response

We have received user complaint about the device registration failing the build. If you are using an Apple ID based connection and want to register a new device the autocodesign logic throws this error:
failed to manage code signing: failed to ensure test devices: failed to register Bitrise Test device on Apple Developer Portal: failed to unmarshal response: json: cannot unmarshal string into Go struct field .data.device of type spaceship.DeviceInfo

It is happening because
{ device: device }

returns the following format
{
"device":"<Spaceship::Portal::Device id="ABCDEFG", name="Test name", udid="00000001-00000000000001", platform="ios", status="c", model="Test model", device_type="iphone">"
}

and the Go code expects a valid json and also different field names for some of them (like the device_type ). Here is a link to the Go struct: https://github.com/bitrise-io/go-xcode/blob/a8f24205effe4374f97a1ace69ec388b0ec4aa39/autocodesign/devportalclient/spaceship/devices.go#L25
The list_devices function uses this object transformation and applying it solved the issue.

@tothszabi is it possible to reproduce the issue? and see if this change resolves the issue?

@shams-ahmed It is possible to reproduce the issue but by doing so you will burn a valid device id which cannot be reused for testing. So what I done was to manually construct a ruby object with previously returned data and tested with that and saw that it does resolve the issue.


".." in paths incorrectly escaped

I have an include path "foo\..\bar". In Run-ClangJobs, the backslashes are escaped, so it yields "foo\\..\\bar". However, commit 273473b7f96301a4289e64aecea435e2de276f6c broke this: now it is escaped to "foo\..\\bar". Now my include directory's are not found.
A fix which works for me, is changing
# make sure escaped double quotes are not messed up
$clangConfigContent = $clangConfigContent -replace '\\([a-zA-Z0-9_/\-\\])', '\\$1'

to
# make sure escaped double quotes are not messed up
$clangConfigContent = $clangConfigContent -replace '\\([^"])', '\\$1'

So to actually do what the comment says.
Alternatively, changing the regex to '\\([a-zA-Z0-9_/\-\\\.])' would also work, but might miss other cornercases.

Thank you for your feedback. We'll include your fix in the next release (v4.1).


Auto-approval controller

/hold

A few things about this PR:

I don't know how the roles were generated, make generate fails. I do need some updated permissions, in particular for the approval subresource.
Right now it does a replace for the pkg module. Otherwise I have to commit that before I can use. Maybe go workspaces can fix this. But for now, after this merges, I can do a follow up PR that sets the modules up right. Something is wrong with how we're doing this.
I added a way to build a docker image locally (not in the Dockerfile) so that we can test when using replace - this will tag the image your user name and you can put it with that name. Works for now, a bit awkward.

With this and https://github.com/nephio-project/nephio-example-packages/pull/35, we will be able to just apply a PVS like this:
apiVersion: config.porch.kpt.dev/v1alpha2
kind: PackageVariantSet
metadata:
  name: edge-clusters
spec:
  upstream:
    repo: nephio-example-packages
    package: nephio-workload-cluster
    revision: v3
  targets:
  - repositories:
    - name: mgmt
      packageNames:
      - edge1
      - edge2
      - edge3
      - edge4
    template:
      annotations:
        approval.nephio.org/policy: initial

and those 4 clusters will be automatically created, registered with Nephio, and bootstrapped (well, with #232 also)

/hold cancel


Require app protection policy now available for Teams

Hi Microsoft Teams should now work with app protection polices. Therefore the Teams application can be added to the list. See message center requests below
Microsoft Teams: Require app protection policy conditional access grant
MC266463 · Published 2 Jul 2021
Service
Microsoft Teams
Tag
ADMIN IMPACTNEW FEATUREUSER IMPACT
Message Summary
This release of app protection policy based Conditional Access in Microsoft Teams will help protect your organizational data on devices your employees use by ensuring that only users with Intune app protection policy can access Microsoft 365 services from Teams.
This message is associated with Microsoft 365 Roadmap ID 87773
When this will happen:
Teams support for app protection policy based Conditional Access will be available as of July 31, 2021
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bd934939-4dbb-3a92-f996-56b9557f49ac
Version Independent ID: 3cda6b81-26e8-c9ac-e768-d912636a461b
Content: Grant controls in Conditional Access policy - Azure Active Directory
Content Source: articles/active-directory/conditional-access/concept-conditional-access-grant.md
Service: active-directory
Sub-service: conditional-access
GitHub Login: @MicrosoftGuyJFlo
Microsoft Alias: joflore

@nikki-c
Thanks for your feedback! We will investigate and update as appropriate.

@nikki-c
Thank you for pointing this out! I've created a PR to update the documentation and it's currently waiting for the author to review and sign off.
I will now close out this issue. Please allow some time for the author to review and the changes to reflect.
Thank you for your time and patience!


Cannot create or grant roles

Running the following query:
BEGIN;
    create role test_role;
    create user test_user with encrypted password '***';
    grant test_role to test_user:
COMMIT;

Results in the following error:
ERROR: permission denied to create role (SQLSTATE 42501)

The query was performed from the UI and also programmatically with the DB owner credentials.
I tried to workaround this by creating two users through the neon UI console and then granting one user to the other (just a workaround so I can test the rest of my migration), but I was not able to grant one user to the other:
grant one_existing_user to another_existing_users;

Results in:
ERROR: must have admin option on role "one_existing_user" (SQLSTATE 42501)

The use case:
My existing migrations depend on test_role to exist and expect test_role to be granted to test_user. test_role is used in the migration scripts whilst test_user is used by the application to query the database. The migrations grant limited table access to test_role. In the future, test_role can be granted to other users to be used by other applications.
Upon further investigation, it seems the only user that has the ability to create roles is the zenith_admin user.
Is it possible to give this permission to the DB owner as well?
Seems that this is locking me out of my own DB a bit.

Any acknowledgment of the issue ?
Am I doing something wrong here ?

Hey! Sorry for the slow reply. We are going to start working on this soon. Some details: https://github.com/neondatabase/neon/pull/2104 We have some pipeline of features/fixes in progress, so I think we probably get to this one in September.

Thanks for the update!

Hello @kelvich were there any advancements for this one?

Any updates @kelvich ?

Hey @Ranguna! Not really unfortunately. We've prioritized branching release and several integrations in favor of allowing manual user managements. Now we mostly busy with launching more aws regions and consumption metering -- we select areas of work which receive most of complains. So it is still on a roadmap waiting to be implemented.

All right, thanks for the info!

Hello @kelvich :)
Any news about this one?

Hey, @Ranguna
Now we started some preparatory work for this =) High chances that it will be shipped in Q1.
As a side note -- probably we can make our roadmap more public to make it easier to track. WDYT @stepashka? Should we just open neon roadmap?

@kelvich amazing news, keep up the awesome work everyone!

Hello @kelvich, I saw that the #2104 was moved to draft, are there any updates that can be shared other than that?

Hello @kelvich!
Are there any uodates that can be shared about this?

Hey, @Ranguna! Yes, we've recently merged https://github.com/neondatabase/neon/pull/3891 and few other patches, and will release it to prod soon. cc @save-buffer

Wow best news I've had all week, and it wasn't a calm week xD
Thanks for the update, can't wait to take neon for a spin once again!

Hello @kelvich !
Any news on this one?

Hey! You can create roles now: https://neon.tech/docs/manage/roles#manage-roles-with-sql
Forgot to close this issue. Closing it now.

Nice!!!!
Thanks for all the effort and keep up the amazing work ♥


Allow ratings at Query level, in addition to QueryGroup

We have a client who wishes to just specify queries, without Topic or QueryGroup blocks. However, the current behaviour requires ratings to be set at QueryGroup level, applying to all Query entries underneath - we required ratings to be set on individual Query entries. This PR adds that behaviour, allowing ratings to be specified at both Query and QueryGroup level.

Ratings at Query level override any set at QueryGroup level (QueryGroup ratings are ignored);
If a Query has no ratings, it will use ratings from the QueryGroup (as per current behaviour).

I hope this makes sense - let me know if it doesn't.

Absolutely @mattflax: as you already got , RRE has born from real use cases...I never met such scenario but I agree with you that can be useful


Thanks, everything works perfectly 😃


GateFamily: tag validation

Adding general validation of gate tags to GateFamily, as described in https://github.com/quantumlib/Cirq/pull/5063#discussion_r826415632
Replaces https://github.com/quantumlib/Cirq/pull/5063
@tanujkhattar

This PR is ready for review again!


pld opener

need someone better then me to really test it,

It's working well from what testers are telling me, I did add a delay for tank buffs though so they can get the most amount of gcds inside the buff window.


Import print() from future for 2.x

Calling a keyword argument on print is a syntax error in Python 2.x.

Interesting. I've been running generate.py in python 2.7 and it's been working. How can that be? I don't know much about python.

I don't know. This recently broke with one of the diffs landed today. Assuming you were on the same code, are you sure you're using 2.7? Virtualenv can sometimes cause you to use a different version of python if you're using that.

@jyegerlehner @maxhodak
https://github.com/ibab/tensorflow-wavenet/blob/4dafacbc42024797bf022eca6ca4f87d8c898e52/generate.py#L189 had been broke in Python2.
In Python2, print was a statement and not a function (so you could write print "foo"). In Python3, print is completely function, and can take some optional parameters, such as end.
from __future__ import print_function magic injects Python3 style print function into Python2. So it enables Python2 to run the newer codes.

Why didn't Travis complain? Aren't the generate tests run in CI as well?

@lemonzi
No, it looks current CI only uses test/test_generation.py and check the model's stability, not generate.py's. If we want to guarantee the stability of generate.py itself, we might need more tests.

I think just importing something from generate.py in anything used by the tests should be sufficient to catch syntax errors

On Sep 30, 2016, at 12:33 AM, mecab<EMAIL_ADDRESS>wrote:
@lemonzi
No, it looks current CI only uses test/test_generation.py and check the model's stability, not generate.py's. If we want to guarantee the stability of generate.py itself, we might need more tests.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Right. Introducting static lint such as pyflakes is another option.

+1 for a linter
On Fri, Sep 30, 2016, 08:52 mecab<EMAIL_ADDRESS>wrote:

Right. Introducting static lint such as pyflakes is another option.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ibab/tensorflow-wavenet/pull/108#issuecomment-250736660,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADCF5uLEIevCtN6eD5LQp_L-lhQFgj1Sks5qvQYUgaJpZM4KJjMi
.


refactor: app-express to deno

May need to use https://oakserver.github.io/oak/ in lieu of express for Deno

Express is being deprecated in lieu of opine on top of Deno


Allow dependencies that take parameters

I'm not sure if this is possible, but consider the following case:
run stuff:
    cd {{stuff}} && python main.py

visualize stuff:
    python src/visualize.py {{stuff}}

run_visualize stuff:
    just run {{stuffl}}
    just visualize {{stuff}}

Is there a way to create run_visualize recipe without subsequent executions of just from the main just process?

Is there a good default value you could give to stuff? If so, you could turn it into a variable:
stuff = "foo"

run:
    cd {{stuff}} && python main.py

visualize:
    python src/visualize.py {{stuff}}

run_visualize: run visualize

You could then override it on the command line like so:
just stuff=bar run

I'm afraid I can't, that's the whole problem, I thought about using the default value but I want to make sure that this particular value is always passed by user

Hmm, darn, this is a tricky one.
The only solution I can think of is one which would be pretty weird. Basically to allow dependencies that take the exact same number of arguments, and pass the arguments of the dependee through, which would allow:
run stuff:
    cd {{stuff}} && python main.py

visualize stuff:
    python src/visualize.py {{stuff}}

run_visualize stuff: run visualize

This would be preeeeetty magical though. An additional constraint could be that they must have the same name, which would mean that the above would still work, but the following wouldn't:
run bar:
    cd {{stuff}} && python main.py

visualize foo:
    python src/visualize.py {{stuff}}

run_visualize stuff: run visualize

Since foo != stuff and bar != stuff.
I can't decide whether this is super weird or not.

I'm not really sure this is a good idea, because that would break backward compatibility, consider
foo arg: bar baz

what if bar and baz don't take any arguments? I think a better option would be to allow the user to provide the arguments somehow so maybe something like
foo arg1 arg2: (bar arg1 arg2) (baz arg2)

What do you think?

When I think about it now, maybe it's a better idea to introduce something like that within the body of the recipe? I'd think that a lot of the times you want to run the recipes somewhere in the middle of different operations like so:
foo arg1 arg2:
    # some bash commands here
    bar arg1 arg2  # run recipe bar here
    # more bash commands
    baz arg2 # run another recipe

That way you don't need to change the dependencies syntax, and if user wants dependencies to take arguments then he'd need to call them by hand from within the body of the recipe. But now there should be a standardized way to mark a line in the body that it starts a recipe, maybe similar to how @ sygil works?

If bar and baz took no arguments, then they just wouldn't get passed any, so it would be okay for backwards compatibility. foo arg1: (bar arg1) would definitely be better for readability, and would be less magical.
Going the sigil route, I think it would be better to have a sigil that meant the opposite, that this line wasn't a normal recipe line, and was a call to a dependency or set a variable.
Still not sure about either route, since recursively calling just is a viable solution.

Oh I meant the sygil to be working in the way you described it - something to describe a non-normal line of recipe

Thinking about this a bit; I think that introducing special lines within recipes would be a big step*, so the solution I like right now is your version of parameter passing, using parenthesis for grouping:
foo arg1 arg2: (bar arg1 arg2) (baz arg2)

I'm not sure when I'll be able to get to it though, I'm working on a parser-generator, which is taking all my attention at the moment.

Never say never though! This would also allow intra-recipe assignments, which have been requested before.

I started to implement this, but I ran into an issue. Check out the following:
foo a: (baz a)

bar a: (baz a)

baz a:
  echo {{a}}

bob a b: (foo a) (bar b)

If we run just bob x y, then baz will be invoked with both x and y as arguments from foo and bar recipes. Hmmm, I suppose this could be statically detected though.

Is this bad? It looks like that's exactly what should happen...

I'm not sure if it should be allowed. Up until now, any recipe would only ever run once in any particular run.
There are two options here, either treat those two instances of baz that are called with two different arguments as different recipes and run baz twice, or treat them as two conflicting calls to the same recipe, and disallow it.
My initial reaction was that I should disallow it, mostly because that's my usual strategy when extending just. It's usually better to disallow too much and then extend what's allowed, as opposed to allow too much but then disallow what was once allowed. Both to avoid adding weird misfeatures, but also since the former kind of changes are backwards compatible, whereas the latter aren't.
However, it might be reasonable to treat them as separate recipe invocations, but only run them once if the arguments match. Can you think of a case where this would be useful? I'll try to come up with one tomorrow, but it's bedtime 😪

I also ran into this issue-- one other consideration for this is how variadic parameters are sent to dependencies as well. My vote: test +version: build +version means that test 1.0 1.1 1.2 would have dependency build 1.0 1.1 1.2 whereas test +version: build version would have dependencies build 1.0, build 1.1, and build 1.2.

I have just run into a similar issue where a dependency requires the argument. I think @fuine's suggestion of having a way of running recipes from within other recipes would be a suitable alternative. In my case I need something like
# several recipes require the same preparation
prepare xyz:
    # do something with xyz

build target:
    # do stuff
    prepare {{target}}_output
    # continue doing stuff

The current restriction on dependencies not having arguments could stay as it is which would prevent recipes being run twice with different arguments (unless explicitly called).
Could maybe introduce a new syntax to prevent recipes overriding existing commands. Something like & that is never valid bash. eg
build target:
    &prepare {{target}}_output

@tpoliaw One possibility to work around this would be to invoke just recursively, i.e.:
build target:
    # do stuff
    just prepare {{target}}_output
    # continue doing stuff

It feels a little unsatisfying, but it should work.
I'd like to keep just shell agnostic, so I'm hesitant to add syntax which might conflict with commands in non-bash shell languages. One way to do it, although it's very weird looking, would be to put the marker for an intra-recipe invocation somewhere in the leading whitespace for the line, like so:
build target:
    # do stuff
:   prepare {{target}}_output
    # continue doing stuff

Since a : can't start a regular justfile line, and it's not part of the line text, the parser can figure out what's going on, and it doesn't conflict with bash syntax. I used : since it's the character that introduces recipe dependencies, so it feels appropriate.
I'd have to figure how/if these intra recipe calls would participate in dependency resolution. I.e. are transitive recipe dependencies re-run every time they're invoked?

That's what I've been doing so far but it falls over if the justfile is not in the current directory tree. eg  running just --justfile ~/.justfile deploy outside of your home directory will fail to find the correct recipes when just is run recursively.
I like the idea of an opening : although it'd break any syntax highlighting that relies on it being similar to make. Would an opening & be more likely to clash with a posix shell than the @ used for silent commands?

@tpoliaw, ahh, gotcha that's unfortunate.
It's not so much that & is more likely to clash with @, it's that I think it was a mistake for me to support @ in the first place. I'd like it to be possible to use any kind of shell or programming language with Just, and any kind of syntax (like @ or &) that is part of the recipe lines can potentially conflict with the syntax of the recipe language.

I've started working on this feature in #555. I have a couple of open questions around syntax and symantics, so do check the draft PR out and and let me know how you feel either way!

This has been implemented and included in v0.5.2, which I just published to crates.io. Releases should be available soon here. (@clarfon I opened #558 to track expanding dependencies w/variadic arguments, which I quite like, although it'll be tricky to implement.)


Optionally use faster string distance functions

I set up a benchmark for album matching to investigate #609 and found that (after fixing some obvious problems) well over half of the matching time can be spent on edit distance calculation. There are some reasonable-looking C implementations of Levenshtein available:

editdistance
python-Levenshtein
jellyfish

We should consider letting beets use these optionally if they're installed (and fall back to our simple Python implementation if they're not).

this could be closed now right? since jellyfish is now required.

@jrobeson indeed. Thanks!


Get ASV running on trivial benchmarks

trivial benchmarks can now be seen at http://warrenwk.com/streaming_pileupy/


Upgrade solution from Visual Studio 2015 to 2022.

Upgraded from v140 (Visual Studio 2015) to v143 (VS2022) and SDK version 10.0.19041.
Visual Studio versions older than 2019 are no longer supported by Microsoft.

Thanks for the patch but I am not sure this is entirely right. MS said it ended mainstream support for vs2015, but "extended" support is still there. See here what this means: https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-servicing
Given that it is actually straightforward to change "toolchain version", I think we should keep code/msbuild files vs2015 for now.

I just re-read that article I linked and realized you're correct; VS2015 is still supported for a couple more years. I guess I'll close this PR.


Load new characters?

When I upload new characters, it always gives me an error. How can we fix this? Also there seems to be no local copy saved in my gdrive.

thanks for the info ❤ please test new v2.3


imatcopy: wrong info on invalid ldb

https://github.com/xianyi/OpenBLAS/blob/4d0b7fbec04c95c90291938a5974f00673e10e68/interface/imatcopy.c#L103-L104
https://github.com/xianyi/OpenBLAS/blob/4d0b7fbec04c95c90291938a5974f00673e10e68/interface/imatcopy.c#L108-L109
should all return info = 8.
This is likely a copy&paste error from omatcopy, where ldb is the 9th argument. imatcopy has one argument less.

Good catch, thanks