- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 6 Feb 2024 15:51:15 -0500
- To: Nathan Rixham <nathan@webr3.org>, public-webid <public-webid@w3.org>
- Message-ID: <80d2f322-fed5-4c3b-b89c-159f56dc0d3c@openlinksw.com>
On 2/6/24 11:54 AM, Nathan Rixham wrote:
> 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.
Indeed, those of us who have consistently advocated for media-type
agnostic specifications (myself included) are not merely reflecting in
hindsight. Thanks for the reference to that older specification.
For what it’s worth, the current debates surrounding the inclusion of
JSON-LD echo past discussions about incorporating Turtle alongside
RDF/XML, among others. Technical specifications should not serve as
branding tools. I STRONGLY doubt that TimBL would endorse such an
approach to spec creation.
The integration of JSON-LD into the WebID specification was delayed
primarily because, until version 1.1—which was released years after two
variants of the WebID spec—it did not support relative URLs
<https://datatracker.ietf.org/doc/html/rfc1808>. This limitation was a
significant barrier because relative URLs are crucial to the open
standards and principles of Linked Data. Essentially, JSON-LD's earlier
versions presented a contradiction in its application of Linked Data
Principles through a JSON-based format.
Currently, I would be quite surprised if TimBL had any reservations
about JSON-LD 1.1 being considered on par with RDF-Turtle in the context
of an updated WebID Spec. His concerns were justifiably focused on the
issue with relative URLs
<https://www.w3.org/DesignIssues/Relative.html>. I have even proposed
discussing this matter directly with him, should it prove to be the last
obstacle.
Kingsley
>
> 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
> >>>
> >>>
>
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Home Page:http://www.openlinksw.com
Community Support:https://community.openlinksw.com
Weblogs (Blogs):
Company Blog:https://medium.com/openlink-software-blog
Virtuoso Blog:https://medium.com/virtuoso-blog
Data Access Drivers Blog:https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
Personal Weblogs (Blogs):
Medium Blog:https://medium.com/@kidehen
Legacy Blogs:http://www.openlinksw.com/blog/~kidehen/
http://kidehen.blogspot.com
Profile Pages:
Pinterest:https://www.pinterest.com/kidehen/
Quora:https://www.quora.com/profile/Kingsley-Uyi-Idehen
Twitter:https://twitter.com/kidehen
Google+:https://plus.google.com/+KingsleyIdehen/about
LinkedIn:http://www.linkedin.com/in/kidehen
Web Identities (WebID):
Personal:http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
:http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
Received on Tuesday, 6 February 2024 20:51:25 UTC