Re: Observations on WebID definition and specification

út 6. 2. 2024 v 17:54 odesílatel Nathan Rixham <nathan@webr3.org> napsal:

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

Good point. Serializations indeed have a lifespan, even though we often
hope they'll last indefinitely. If we had defined and specified a
serialization neutral WebID earlier, it would have prevented a lot of
misunderstandings by giving everyone a clear, shared definition. This kind
of groundwork not only promotes flexibility but also helps avoid the need
for disruptive changes, contributing to the project's stability and unity.


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