Re: WebID and Content Negotiation

On 1/28/22 2:55 AM, Henry Story wrote:
>
>> On 27. Jan 2022, at 19:51, Martynas Jusevičius<martynas@atomgraph.com>  wrote:
>>
>> On Thu, Jan 27, 2022 at 7:19 PM Jacopo Scazzosi<jacopo@scazzosi.com>  wrote:
>>> Hi all,
>>>
>>>> Could we come to a consensus that content negotiation is optional for
>>>> current and future WebID work?
>>> I agree that it should remain optional, as per the current WebID spec/draft:
>>>
>>> a) conneg tends to be incompatible with hosting of static resources
>>> b) conneg comes with its own complexity, which should not be forced upon
>>>    adopters of the spec
> Content-negotiation works with static resources too.
>
> You can have 1 static resource served with 1 mime type and a client can content negotiate
> in order to receive that mime-type, or you can have multiple ones.
> There is documentation on the W3C Web site to help with how to set that up with Apache.
> https://www.w3.org/TR/swbp-vocab-pub/
>
> I serve my WebID profile following that in
> Turtle, N3, NTriples and RDF/XML.
>
> https://bblfish.net/people/henry/card#me
>
> But I could also just have published Turtle if I wanted to.
>
>>> In practice, this entails that a client asking for a specific serialization
>>> format might:
>>>
>>> - receive a response in the requested format
>>> - receive a "406 Not Acceptable" response if the requested format is not
>>>   supported by the publisher but basic conneg is
>>> - receive the response in a different format if the publisher does not support
>>>   conneg
>>>
>>> I'm happy with all three implications.
>> I think at this point we need to put the prose behind us and make HTTP
>> request/response examples for each use case, in order to remove any
>> ambiguity. Request examples:
>>
>> 1. No format preference (canonical format is Turtle)
>>
>> GET /webid
>>
>> 2. Canonical format (Turtle) is preferred
>>
>> GET /webid
>> Accept: text/turtle, application/rdf+xml;q=0.8
>>
>> 3. Non-canonical RDF format is preferred and supported by the server
>>
>> GET /webid
>> Accept: application/rdf+xml, text/turtle;q=0.8
>>
>> 4. Non-canonical RDF format is preferred and *not* supported by the server
>> a. without fallback
>>
>> GET /webid
>> Accept: application/rdf+xml
>>
>> b. with Turtle as fallback
>>
>> GET /webid
>> Accept: application/rdf+xml, text/turtle;q=0.8
>>
>> 5. HTML is preferred and supported by the server
>>
>> GET /webid
>> Accept: text/html, text/turtle;q=0.8
>>
>> 6. HTML is preferred and *not* supported by the server
>> a. without fallback
>>
>> GET /webid
>> Accept: text/html
>>
>> b. with Turtle as fallback
>>
>> GET /webid
>> Accept: text/html, text/turtle;q=0.8
> Thanks Martynas Jusevičius, that is a good summary.
>
> The spec just tells us what the mime type by default is, so that
> client writers can have some idea of the minimal requirements they
> need to satisfy for interoperability.
>
> Without the default, clients would need to have 10 parsers around,
> and it actually keeps growing now with RDF* for example recently, N3 soon,
> We may then even want clients to take GRDDl into account.
> Here are just the RDF mime types I have registered for my server
> https://github.com/co-operating-systems/Reactive-SoLiD/blob/master/src/main/scala/run/cosy/http/RDFMediaTypes.scala
>
> I am in favor of having clients support many formats. For example
> this is what my server (when working as a client) uses when making
> requests at present
> https://github.com/co-operating-systems/Reactive-SoLiD/blob/master/src/main/scala/run/cosy/http/RdfParser.scala#L33


Hi Henry,


>
> But if we want people to be able to join the community easily, we can’t
> just before they even get going ask them to write 20 parsers for the
> same data structure. I think it is obvious how that would put people off.


I do believe anyone has every indicated, insinuated, or implied what 
you've stated above.

Making WebID-Profile Document Type specificity doesn't in anyway 20 
parsers, or the like.

 From my vantage point, we can guide adopters though the process by 
keeping the following distinct and loosely-coupled:

 1. WebID specs
 2. WebID Profile Doc specs
 3. WebID-TLS protocol
 4. Client implementation guidelines
 5. Server implementation guidelines

BTW -- How about a narrative that starts with WebID Profile Document 
rather than a WebID? That way, Relative HTTP URLs comes into play as the 
basis for constructing WebIDs.

*JSON-LD Example.
*

|## JSON-LD Start ## { "@context": { "@base": "#", "name": { "@id": 
"http://schema.org/name", "@type": 
"http://www.w3.org/1999/02/22-rdf-syntax-ns#langString" }, "sameAs": { 
"@id": "http://www.w3.org/2002/07/owl#sameAs", "@type": "@id" }, 
"description": { "@id": "http://schema.org/description", "@type": 
"http://www.w3.org/1999/02/22-rdf-syntax-ns#langString" }, 
"mainEntityOfpage": { "@id": "http://schema.org/mainEntityOfpage", 
"@type": "@id" }, "mainEntity": { "@id": "http://schema.org/mainEntity", 
"@type": "@id" }, "title": { "@id": "http://schema.org/title", "@type": 
"http://www.w3.org/1999/02/22-rdf-syntax-ns#langString" } }, "@graph": 
[{ "@id": "#netid", "@type": "http://schema.org/Person", "sameAs": [ 
"https://twitter.com/kidehen#netid", 
"https://linkedin.com/in/kidehen#netid" ], "name": { "@value": "Kingsley 
Uyi Idehen", "@type": 
"http://www.w3.org/1999/02/22-rdf-syntax-ns#langString" }, 
"description": { "@value": "A document about me", "@type": 
"http://www.w3.org/1999/02/22-rdf-syntax-ns#langString" }, 
"mainEntityOfpage": { "@id": "doc", "@type": 
"http://schema.org/WebPage", "mainEntity": "#netid", "title": { 
"@value": "A Personal Profile Document", "@type": 
"http://www.w3.org/1999/02/22-rdf-syntax-ns#langString" } } }] } ## 
JSON-LD End ##|

*RDF-Turtle Example.*

## RDF-Turtle Start ##

@prefix schema: <http://schema.org/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix like: <http://ontologi.es/like#> .
@prefix twitter: <https://twitter.com/kidehen#> .
@prefix linkedIn: <https://linkedin.com/in/kidehen#>.
@prefix : <#> .


:doc
a schema:WebPage;
schema:title "A Personal Profile Document"@en ;
schema:mainEntity :netid .

## About Me

:netid
a schema:Person ;
schema:name "Kingsley Uyi Idehen"@en ;
schema:description "A document about me"@en ;
owl:sameAs linkedIn:netid, twitter:netid ; # changed linkedin:netid to 
linkedIn:netid
schema:mainEntityOfpage :doc .

## RDF-Turtle End ##


Both examples turn this mailing post into a WebID-Profile Document. 
What's the problem with that?

WebIDs and WebID-Profile Documents are of co-equal importance in this 
journey. Fixating on "WebID" is rife with problems that have stalled 
adoption en masse.

Note, I am no stranger to Solid -- FWIW.

Kingsley

>
> I actually wrote up a little table in August showing how defaults on
> the server translate to requirements on the client
>
> https://github.com/w3c/WebID/issues/3#issuecomment-898951657
>
> Since we already have so many deployed WebIDs and it is
> central to the Work on Solid, I think that we would need
> to do some empirical work to find out what the options are
> for a way forward.
>
> I think we should be guided by interoperability needs of applications
> that have real momentum. Otherwise this could well be a ”number of
> angels that can fit on a pinhead” type discussion.
>
> Henry
>
>>> Best regards,
>>> Jacopo.
>>>
>>>
>

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