- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 9 Feb 2024 15:13:00 -0500
- To: Martynas Jusevičius <martynas@atomgraph.com>, public-webid <public-webid@w3.org>
- Message-ID: <b9c1cd81-fed5-4f2f-8603-af68d976b158@openlinksw.com>
Hi Martynas,
On 2/9/24 2:15 PM, Martynas Jusevičius wrote:
> 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/XMLsyntax, or an
> equivalent RDF graph serialization, for SPARQLQuery forms DESCRIBE and
> CONSTRUCT)."
>
> For RDF graphs, no mandated serialization, just an example.
Your question cannot be answered in a simple response. For starters, we
have this age-old issue of "WebID" being an overloaded term that means
different things to different people.
To me, a WebID is fundamentally an HTTP URI-based identifier that names
an Agent, unambiguously.
The definition and application of a WebID should not be constrained by
the content-type of a WebID Profile document or any specific
serialization format used during data transmission. Naturally, a
document entitled "WebID Identity and Discovery" could include detailed
sections on WebIDs, WebID Profile Documents, and related topics.
Concerning SPARQL, using it as an example might not be the best choice
because the body of a SPARQL query' is Turtle. Essentially, creating a
SPARQL query processor imposes the need to parse Turtle. This
requirement mirrors the situation with WebID: implementing WebID in any
application (whether client-side or server-side) inevitably means
developing a parser for at least one content-type associated with a
WebID Profile document.
A suggestion:
We've already collectively made progress regarding the WebID
Specification doc i.e., fixing its title which brings coherence to some
key definition in its body e.g., what is a WebID.
We are now trying to architect a way forward, that attains consensus,
with regards to addressing introducing JSON-LD on par with Turtle.
A little background, and I apologize if this comes across as repetitive
to some:
JSON-LD not being on par with Turtle is the consequence of the following
issues from the past:
1. It didn't exist when this journey started.
2. Its initial incarnation didn't have support for relative HTTP URI
i.e., incompatible with the notion of "#" based WebIDs.
Those issues are the deeper reasons why it was left out back then, but
they've been addressed in JSON 1.1.
The challenge we face today mirrors the historical transition from
*RDF/XML to Turtle* during the FOAF+SSL era. It involves shaping the
specification to reflect and adapt to *existing developer preferences
and practices*, rather than covertly prescribing an impractical
alternative that's out-of-touch with current trends.
I am going to write a separate post titled "What is a WebID
Specification trying to Enable?" .
Kingsley
>
>
> 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
>
--
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 Friday, 9 February 2024 20:13:09 UTC