Re: Observations on WebID definition and specification

út 6. 2. 2024 v 14:29 odesílatel Martynas Jusevičius <martynas@atomgraph.com>
napsal:

> On Tue, Feb 6, 2024 at 12:59 PM Melvin Carvalho
> <melvincarvalho@gmail.com> wrote:
> >
> >
> >
> > út 6. 2. 2024 v 10:24 odesílatel Martynas Jusevičius <
> martynas@atomgraph.com> napsal:
> >>
> >> Sorry to nitpick, but Solid is not a W3C spec.
> >>
> >> Why can’t we use SPARQL (Protocol) or SHACL for reference? These are
> some of the most succesful RDF specs IMO.
> >
> >
> > Indeed this is correct.
> >
> > I believe there's a fundamental misunderstanding going on that Marynas
> is expressing well
> >
> > Having SPARQL that is not tied to a serialization is useful, in itself.
> >
> > Solid could then take SPARQL and use it in its ecosystem.  It could even
> tie SPARQL and use it with Turtle.
> >
> > This is the nature of additive composable specs, of which WebID should
> be one, and is not now, because it is not fully defined or specified.  That
> is the heart of the problem.
> >
> > Specs operate on the principle of modularity and loose-coupling.  Turtle
> doesnt need to know about SPARQL.  And SPARQL doesnt need to know about
> Turlte.  But SPARQL can be used with Turtle.
> >
> > Similarly WebID need not be tied to Turlte AND JSON-LD.  But it MUST be
> defined and specified.
> >
> > At this point I would consider attempts to add breaking changes to WebID
> which add MORE serializations, and implementations details, and BEFORE the
> concept of WebID has been defined in a serialization neutral way harmful.
> >
> > You have to define and specify SPARQL before you can use it with
> Turtle.  Or you are putting the cart before the horse.
> >
> > The SPARQL spec is well defined and specified.  That's precisely what
> makes it useful.  WebID cant start branching into different serialization
> strategies before it is defined and specified.  Attempting to that will
> kill the project, if it hasnt already.
> >
>
> Absolutely, this is what I was trying to emphasize.
>
> And this specification orthogonality is not an accident, it's one of
> W3C principles:
> "Orthogonal abstractions benefit from orthogonal specifications."
> https://www.w3.org/TR/webarch/#orthogonal-specs
>
> Related: https://www.w3.org/blog/2009/orthogonality-of-specification/
>
> I don't see how we can choose to ignore such a foundational principle.
>

I think I can explain this.

So, when we made WebID at TPAC that's when the serialization discussions
came in, the definition was Nathan and Henry was tasked with reformulating
the specs, although he was given his own say.

Henry's comment was: "This seems more like a branding conversation than a
technical one."

Timbl replied: "This is about branding"

Henry nodded.

So the orthogonality was put one side and Turlte was selected together with
only fragids (later it was argued against fragids only).  It was a brand.
It was a tactic.  It was a bet.

Folks that say it was always a mistake are doing so with the benefit of Dr.
hindsight.

It was a bet that did OK, but didnt do as well as we'd all have liked.
That's how we ended up where we are.

The principle here is that the orthogonality principle was put aside
because there was only one mandatory seralizations.  So the two things were
put together.

Now that some want to fork the original concept. the orthogonality
principle comes into play.  If you have points of flexibility you seed
separation of concerns.

That is why technically Marynas' point becomes so important, in fact, it
becomes make or break.

As Martynas says, it's a foundational principle.


>
> >>
> >>
> >> On Tue, 6 Feb 2024 at 09.58, Jacopo Scazzosi <jacopo@scazzosi.com>
> wrote:
> >>>
> >>> Hello Kingsley,
> >>>
> >>> > Who has implementation concerns regarding this direction? Ideally,
> they should identify themselves and participate in the discussion.
> >>>
> >>> I don’t want to speak for others but, off the top of my mind:
> >>>
> >>> - Wouter has made this point multiple times, one of which in [1].
> >>>
> >>> - Sarven has made this point at least once in [3] (and you have +1ed
> that comment).
> >>>
> >>> - Solid appears to require clients to request "WebID Profiles” using
> text/turtle or application/ld+json [2] (though I am confused as to whether
> they actually meant to use Content-Type rather than Accept). This doesn’t
> mean we necessarily need to follow what Solid does; I’m just pointing this
> out to keep track of potential breaking changes with respect to what others
> are doing; interop. with the current ecosystem is also a priority.
> >>>
> >>> I can dig up more if you’d like me to, though I would prefer to let
> people speak their own mind.
> >>>
> >>> Best,
> >>> Jacopo.
> >>>
> >>> [1]: https://github.com/w3c/WebID/issues/3#issuecomment-1879750583
> >>> [2]: https://solid.github.io/webid-profile/#reading-profile
> >>> [3]: https://github.com/w3c/WebID/issues/17#issuecomment-1877196126
> >>>
> >>>
>