Re: Replace outdated social models in OWL2 primer

On Fri, Mar 21, 2025 at 18:47 Chaals Nevile <chaals@fastmail.fm> wrote:

>
>
>
> On Friday, 21 March 2025 18:46:39 (+01:00), Pierre-Antoine Champin wrote:
>
> > Hi Markus, all,
> >
> > On 21/03/2025 15:45, Markus Krötzsch wrote:
> > > I actually think that one could implement what is most urgently needed
> here as a minimal, editorial change. This would force us to stay with the
> family examples, but could still do a lot of good.
>
> This is one approach. The other is a more thorough rewrite of the examples.
>
> My inner W3C process nerd* believes that either way these are clearly
> "class 2" editorial changes (in that they do not impact in any way the
> interpretation or implementation of the specification), and can be made as
> a Revised Recommendation on the authority of the Team in the absence of a
> Working Group.
>

I politely disagree re impacting interpretation.

Examples set an example, literally, for how to use a specification. For
understanding what it is *for*. There is an unfortunate mindset around
Semantic Web technologies at W3C, especially but not only  OWL, that says
modelling “isn’t really semantic” unless it is rigidly and logically
structured. The more axioms that kick in, the more “semantics” you have
“captured”. As if meaningfulness were just another mass noun rather than a
situation involving real people’s thinking, communication and lives.

For ~20 years we got tut-tuts about FOAF having non-semantic properties
like foaf:gender which valued sensitivity to human experience over
engineering convenience. In 2025, fortunately, this community has other
healthier outlets for the impulse to over-formalise RDF vocabulary design:
the Shape languages SHACL and (nearby at IEEE,
https://standards.ieee.org/ieee/3330/11119/ ) ShEx. These allow many
divergent graph patterns to be carefully defined for different applications
and workflows, while sharing common vocabulary declared via RDFS/OWL.

If we are updating these old specs without saying why nor acknowledging the
changed technical landscape, it hardly seems worth doing.

So +1 for doing this in a CG, switching to Pizza, or other topics where
there is less at stake like modeling rigidly defined rules and artifacts.

When we were putting together the original specs around RDF it was
commonplace to hear “we need more examples - people won’t slog through
every detail, they’ll skim for the examples”. With RDF/OWL this is
especially important in terms of distinguishing data audiences from
software implementation audiences.

If you’re *building* Jena,  Protege etc you are in the much smaller group
of people who’ll be trying to make sense pf the entire stack of specs. If
you are instead *using* such tools to publish, consume or manipulate data,
you’re much more likely to get your understanding of the purpose and nature
of the technology from the examples.  The kind of improvements we are
talking about absolutely should help people get a more modern and realistic
sense of what the technology is good for. If that means that most of it
lives in a CG note instead, that seems better than trying to disguise the
improvements as tiny fixes…


Nearby:

https://gist.github.com/almereyda/85fa289bfc668777fe3619298bbf0886

https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

https://wiesmann.codiferes.net/wordpress/archives/15187

https://github.com/kdeldycke/awesome-falsehood


Cheers,

Dan




> *(I set up and initially chaired the w3process CG, got the process to
> start evolving again after 7 years of stasis, I was the editor for a few
> years, was part of the AB during the time that the relevant bits of process
> were adopted, and think I qualify as "not completely out there". On the
> other hand, I also made the SVGs that are used to illustrate the lifecycle,
> so there are clear grounds for criticism...)
>
> > > Of course, we should produce a draft first, both to demonstrate that
> the changes remain editorial across all places, and to allow for a
> cross-check from a broader community.
>
> Absolutely agree. Were I part of the Team or AB, I would definitely advise
> that the Team look for some broad support for the kind of changes being
> proposed rather than simply presenting them as done.
>
> A CG, as recommended below, is probably a good place to develop and get
> broad agreement on a proposed change of this nature...
>
> > >If this seems feasible, Pascal and I (and any other of the old editors
> who are up for it) can set up a public repository and propose a draft (or
> maybe W3C has a repo for us, but it would be good to allow public comments).
> >
> > I strongly recommend to do this under the aegis of a community group, if
> only to ensure that all contributions are done under the appropriate
> agreement [1] -- otherwise we may have naughty surprises at the moment of
> migrating this back to REC track.
> >
> > As other pointed out, creating a community group is very easy. But
> otherwise, the RDF-dev CG could be a sensible home for this work (I asked
> the chair, he agrees :-P).
>
> I think the RDF-dev CG is an ideal venue. It falls squarely within its
> stated remit, it has an existing community of relevant people, anyone can
> join or provide input. And if Pierre-Antoine has managed to convince the
> chair that it's reasonable to work on it, we should take advantage of that
> :)
>
> IMHO.
>
> In any case, the next step is probably for at least one {person/group} to
> draft a proposal, and to gather input on what "the community" thinks would
> be a good or bad kind of proposal. (Because without that work, the problem
> turns into a theoretical discussion that can last as long as anyone is
> interested).
>
> There are at least three clear pathways that have been mentioned: the
> original proposal to switch to e.g. the pizza example; Markus' proposal
> here to make a minimal set of changes; or the proposal to annotate the
> examples as a demonstration that modelling the world is hard in part
> because people actually disagree on how they would describe things. And it
> is possible to blend all those proposals into another, in multiple ways.
>
> If there is more than one {person,group} prepared to develop a new
> proposal, then we will have a "beauty contest" on our hands, and the
> RDF-dev CG chair might have to work out how to resolve that and decide a
> winner. Fortunately, that's someone else's problem - and assuming the
> goodwill this community so often demonstrates I doubt it will be a great
> big problem.
>
> So my offer stands to start editing a proposal. I don't yet have a sense
> of which of the above pathways I would prefer.
>
> cheers
>
> Chaals
>
> > In the meantime, we (the team, the process CG) can figure out whether
> these changes need a WG to be published, or whether it is acceptable for
> the team to do it.
> >
> >   best
> >
> > [1] https://www.w3.org/community/about/process/cla/
> > [2] https://www.w3.org/community/rdf-dev/
> >
> > >
> > > Cheers,
> > >
> > > Markus
> > >
> > >
> > >
> > > On 21.03.25 11:29, Sarven Capadisli wrote:
> > >> On 2025-03-21 08:32, Ivan Herman wrote:
> > >>> Good morning Sarven,
> > >>
> > >> Morning! =)
> > >>
> > >>>> On 20 Mar 2025, at 19:45, Sarven Capadisli <info@csarven.ca> wrote:
> > >>>>
> > >>>> On 2025-03-19 09:50, Ivan Herman wrote:
> > >>>> As per current W3C Process's Revising a Recommendation: Editorial
> Changes ( https://www.w3.org/policies/process/20231103/#revised-rec-
> editorial ):
> > >>>>
> > >>>> >If there is no Working Group chartered to maintain a
> Recommendation, the Team may republish the Recommendation with such changes
> incorporated, including errata and Team corrections.
> > >>>>
> > >>>
> > >>> That is correct, but...
> > >>>
> > >>>
> > >>>> Errata include correction classes 1-3. I believe the changes
> discussed in this thread ( https://lists.w3.org/Archives/Public/
> semantic- web/2025Mar/0045.html ) for https://www.w3.org/TR/owl2- primer/
> fall under correction class 2 ( https://www.w3.org/policies/
> process/20231103/#class-2 ):
> > >>>>
> > >>>> >Changes that do not functionally affect interpretation of the
> document
> > >>>
> > >>> … that is not clear at all in this case. At least not for me.
> > >>
> > >> Perhaps the simplest explanation is that the examples in the Primer
> are meant to help the reader better understand the TRs it references.
> Examples are not functional changes. However, the current examples make it
> harder to understand and apply the proposed work correctly, rather than
> helping.
> > >>
> > >>> The problem I see is that this Primer is labeled as a
> Recommendation. Seen from today, this is very unusual. Most primers I know
> (at least nowadays) are published as WG Notes. Indeed, there is no really
> actionable, normative statement in a Primer, and I do not know what would
> be, e.g., the acceptable CR exit criteria. (I remember this was the subject
> of a discussion in the OWL WG, but I do not remember all the arguments…)
> > >>>
> > >>> You may argue that, by the "letter of the law", and exactly because
> there are no normative statements, all changes are simply editorial,
> therefore your aforementioned rule applies.
> > >>>
> > >>> However, in my (personal) opinion, reworking all the examples in the
> primer document represents, essentially, a fundamental rewrite of a
> Recommendation and, by the "spirit of the law", this should only be done
> under the supervision of a chartered Working Group. Not by the team.
> > >>
> > >> I'm not sure how relevant it is to compare a Primer's status today to
> its past. As it stands, owl-primer is a Recommendation, which means it
> follows the corresponding Process, and carries the patents assigned at the
> time ( https://www.w3.org/Consortium/Patent-Policy-20040205/ ).
> > >>
> > >> That said, and because of
> https://www.w3.org/policies/process/20231103/ #revised-rec-editorial ,
> https://www.w3.org/policies/process/20231103/ #erratum , each change
> corresponds to a correction class - and in this case, the changes that are
> under consider appear to fall under https://
> www.w3.org/policies/process/20231103/#class-2 .
> > >>
> > >> The changes to the examples do not fundamentally alter the meaning of
> the Primer. Given the nature of a Primer, any change will typically fall
> under correction class 1 or 2.
> > >>
> > >> As I see it, there is no specific guideline stating that the number
> of changes or as a collection holds any significance under the Process.
> After all, a correction (class 2) change could be introduced incrementally
> - e.g., one per month - without the notion of a "fundamental rewrite"
> applying.
> > >>
> > >>>> I also believe that the reasons for these changes - raised with
> general consensus by multiple community members - are not merely technical
> but extend to expected professional practice, as outlined in the Positive
> Work Environment at W3C: Code of Conduct ( https://
> www.w3.org/policies/code-of-conduct/ ).
> > >>>>
> > >>>
> > >>> I agree that the changes are not merely technical; I would actually
> argue that the reasons for the changes are not technical at all. I have not
> seen anyone arguing on the thread that the document is technically wrong.
> > >>>
> > >>> Wendy or Tzviya were more closely involved with the formulation of
> the CoC, their words have much more weight on that than mine. Suffices it
> to say that, for me, that connection is quite a stretch (without
> diminishing the importance of the original problem leading to this thread
> or the CoC!).
> > >>
> > >> Just to be clear, when I said "technical", I was referring to the
> mechanical process of modifying the document, e.g., "changing example Foo
> corresponds to correction class 2". That aspect, without considering the
> content (semantics) of the change, is purely technical.
> > >>
> > >> As I see it, that alone is sufficient justification for the change.
> > >>
> > >> However, I also wanted to add to the technical argument by
> emphasising that the *necessity* for this change is ethically grounded in
> W3C's work (and I don't mean to speak for anyone, so take this as an
> opinion if anything):
> > >>
> > >> The application of the W3C Conduct is not limited to individual
> behaviour and interactions within the community. It also extends to the
> work that is communicated to the world. Additional examples:
> > >>
> > >> Ensuring that examples in specifications are inclusive and
> considerate of all individuals aligns with the W3C's commitment to Ethical
> Web Principles ( https://www.w3.org/TR/ethical-web-principles/ ).
> > >>
> > >> The Societal Impact Questionnaire (
> https://w3ctag.github.io/societal- impact-questionnaire/ ) encourages
> specification authors and reviewers to critically assess the broader
> implications of their work, prompting considerations of how content,
> including examples, may affect various groups.
> > >>
> > >> Yet another example is with the Vision for W3C (
> https://www.w3.org/TR/ w3c-vision/ ), with the aim to ensure that the web
> is a place where everyone can participate.
> > >>
> > >>>> I suspect the broader W3C and standards community would welcome the
> changes discussed in this thread, and I'm sure there's a way to make it
> work within the process. However, if this is not deemed a class 2 change,
> it would be great to have AB's advice on this.
> > >>>>
> > >>>> Irrespective of the actual path forward (whether editorial, through
> a Working Group, or otherwise), it might help the community to set up a
> workspace where the proposal can take shape (e.g., https://
> lists.w3.org/Archives/Public/public-owl-comments/ and GitHub?). Would you
> be able to follow up on this in https://github.com/w3c/strategy/ or
> coordinate with the Team elsewhere?
> > >>>
> > >>> We have community groups for that kind of thing. If there are enough
> people interested in the subject, a CG can be formed and jointly create a
> CG report with a proposed alternative to the OWL Primer. Though such a
> draft does not have the same weight as a Recommendation, the CG can then
> propose a short-lived WG with a very focussed charter to turn that new
> primer into a recommendation. If the AC accepts that, then issue is solved.
> W3C already has the structures needed for this.
> > >>>
> > >>> That being said, I believe if we open this issue, the problem of the
> normative status of the document will come to the fore during the vote of
> the AC. But that will be a discussion for a later day.
> > >>
> > >> I'd suggest reviewing the proposal (that's yet to be officially made)
> as an erratum and on values-driven grounds, as it seems to be the simplest
> and most applicable option. If that doesn't hold up due to the Process or
> other constraints, I assume the community will follow W3C's recommended
> approach. (Setting up a WG is a lengthy and costly process, but that's
> beside the point here.)
> > >>
> > >> I'd also add that the initial OWL WG charter (
> https://web.archive.org/ web/20070920135644/
> https://www.w3.org/2007/06/OWLCharter.html ) operated under an earlier
> version of the Process ( http://www.w3.org/2005/10/ Process-20051014/ ).
> However, the current state of the charter (
> https://www.w3.org/2007/06/OWLCharter.html ) now references the latest
> Process ( https://www.w3.org/policies/process/ ).
> > >>
> > >> The errata for owl-primer can be tracked at
> https://www.w3.org/2001/sw/ wiki/OWL_Errata
> > >>
> > >> Would love to hear PAC’s or the team’s thoughts on this!
> > >>
> > >>> P.S. I cc this mail to Pierre-Antoine. I am not in charge of the W3C
> Data activity anymore, he is...
> > >>
> > >> I appreciate that as well and would love to know more. Thank you.
> > >>
> > >> -Sarven
> > >> https://csarven.ca/#i
> > >
> >
> >
>
> --
> Charles "Chaals" Nevile
> Using fastmail.fm because it's worth it
>
>