Re: Observations on WebID definition and specification

It's perhaps useful to remember the 2011 also
https://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20111123/

> The Server must publish the document in at least the XHTML+RDFa 1.1
[XHTML-RDFA] serialization format or in RDF/XML [RDF-SYNTAX-GRAMMAR]. The
document may be published in a number of other RDF serialization formats,
such as N3 [N3] or Turtle [TURTLE]. Any serialisation must be transformable
automatically and in a standard manner to an RDF Graph, using technologies
such as GRDDL [GRDDL-PRIMER].

MUST mediatype is the one contentious bit that always changes with time,
and always will.

On Tue, 6 Feb 2024, 16:24 Melvin Carvalho, <melvincarvalho@gmail.com> wrote:

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