Re: Observations on WebID definition and specification

Kingsley,

Please explain to me how WebID as a protocol differs from the SPARQL
Protocol? Both are RDF-based.

SPARQL 1.1 Protocol states:
https://www.w3.org/TR/sparql11-protocol/#query-success

"The response body of a successful query operation with a 2XX response
is either:
* a SPARQL Results Document in XML, JSON, or CSV/TSV format (for
SPARQL Query forms SELECT and ASK); or,
* an RDF graph serialized, for example, in the RDF/XML syntax, or an
equivalent RDF graph serialization, for SPARQL Query forms DESCRIBE and
CONSTRUCT)."

For RDF graphs, no mandated serialization, just an example.


On Fri, 9 Feb 2024 at 14.44, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> Hi Wouter and others,
> On 2/9/24 4:52 AM, Wouter Termont wrote:
>
> Yes. My concerns should have been clear from my previous message: contrary
> to other specs, WebID needs to provide absolute interoperability, which can
> only be achieved through obligatory formats. This is still compatible with
> serialization neutrality (we could let servers provide ALL formats), but
> for practical purposes a limited set of formats seems the better choice.
>
>
> Reflecting on the developments over the years, I would interpret the
> discussions not so much as aiming for "absolute interoperability" but
> rather seeking "broad implementation practicality."
>
> "Absolute interoperability" aligns more closely with the unique
> capabilities RDF and HTTP jointly offer, enabling notation, format, and
> syntax agnosticism at their core.
>
> "Broad implementation practicality," achieved through specific
> combinations of notation, format, and concrete syntax, is inherently
> dynamic. This dynamism has notably impeded WebID's advancement. It's worth
> noting that the current debates surrounding Turtle and JSON-LD mirror past
> discussions when Turtle was introduced alongside RDF/XML. The crux of the
> issue is that specifications thrive as *retrospective standardization of
> existing market trends* rather than *prescriptive mandates* aimed at
> shaping emerging or yet-to-be-established markets.
>
> In conclusion, the ongoing challenge lies in establishing a flexible
> foundation for the WebID specification that addresses current
> implementations while also accommodating future market directions i.e., a
> 'JSON-first' approach regardless of the technical strengths of
> alternatives.
>
> JSON beat out XML as the standard notation, content-type, and concrete
> syntax, years ago. A spec that ignores this reality will not achieve broad
> adoption. Turtle has its place, but that place isn't one that resonates
> with Web Developers.
>
> Personally, I will continue to encourage and support whatever consensus
> exists towards what's now best described as MUST for Turtle and JSON-LD --
> with the sole aim of moving things forward.
>
>
> --
> 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
>
>