Re: WebID and Content Negotiation -- Correction

On 1/28/22 10:15 AM, Kingsley Idehen wrote:
> 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
>
>
>> 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.
>
>
Hi Henry,

I *don't* believe anyone has *ever* indicated, insinuated, or implied 
what you've stated above re parsers.

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