Re: WebID default serialization for WebID 2.x

Hi Kingsley,

On 21.01.22 15:34, Kingsley Idehen wrote:
> On 1/21/22 9:04 AM, Jonas Smedegaard wrote:
>> Quoting Sebastian Hellmann (2022-01-21 14:38:07)
>>> Hi Martynas,
>>>
>>> On 21.01.22 14:11, Martynas Jusevičius wrote:
>>>> Agents should use content negotiation to retrieve the most appropriate
>>>> RDF format. WebID documents are not different from Linked Data in
>>>> general in that respect.
>>> Content negotiation is a cool method to deliver different formats. I
>>> have a question for this one actually. Is there some official document
>>> that describes the relation between content negotiation and linked 
>>> data?
>>> It isn't mentioned here:
>>> https://www.w3.org/DesignIssues/LinkedData.html  and otherwise I only
>>> know this one: https://www.w3.org/TR/cooluris/    . LDP mentions it in
>>> 4.3.2 HTTP GET  . They also follow an approach, where only Turtle and
>>> JSON-LD are a MUST and also define Turtle as the default. Any other
>>> document that is relevant and official here?
>>>
>>> We recently started to put our WebIDs on github.io:
>>> https://kurzum.github.io/webid.ttl  (sufficient security for
>>> non-critical services). Not sure, github.io even allows content
>>> negotiation. It is quite obvious that each additional MUST requirement
>>> in the WebID spec or any WebID spec will add a barrier towards 
>>> adoption.
>>> Not sure, if there are strong use cases for the content negotiation 
>>> MUST.
>>>
>>> I found it quite practical, that you can just put a file on a web 
>>> server
>>> (in this case github.io ) to serve as webid.
>> Yes, simplicity is more practical.
>>
>> Problem in _requiring_ any specific serialization is that it enforces
>> specific complexity of the involved systems - publishers or consumers or
>> both.  Publishers and distributors and consumers each want certain
>> simplicity - but it is not the same (else we would have no debate for
>> these many years!).
>>
>> Having no default but only recommending JSON-LD would not block you from
>> publishing Linked Data serialized as Turtle.
>>
>> Same as western establishments recommending US dollars as reference
>> would not block east asian communities to use Chinese Yen as reference,
>> and anarcists using Ether.
>>
>> My point is that the World is complex, and best we can do is encourage
>> simplification, enforcing it won't help and might cause more damage.
>>
>>
>>   - Jonas
>>
>
> Yes!
>
> There is no way around this problem, so we need to simply use RDF 
> (which is content-type agnostic) properly and not get it tangled in 
> distracting "preferred content format" battles.
>
> Content-Negotiation is a non-issue, fundamentally -- hence its 
> non-existence in any docs about Linked Data Principles.
>
> We have to important artifacts here, lost is perpetual distraction 
> related for content-types:
>
> 1. Agent Denotation
>
> 2. Agent Description
>
> To push a specific content-type, signals the following to me:
>
> 1. Not understanding first principles
>
> 2. Not learning from history
>
> 3. Political games
>
The fact that the web is webby is quite a good thing, i.e. it can adapt 
to endless use cases, but this characteristic also makes it very 
distracting. I agree on the focus you are mentioning here (which should 
be supported by clearly described use cases ).  I would argue for a more 
clear definition of what the webID publisher should/must provide, simply 
to prevent wiggle space. This is potentially foreseeing that people do 
not have an understanding of the architectural concepts or don't care. 
RDF/Linked Data related wiggle spaces are:

1. 200 / 303 , 2. JSON-LD/Turtle/...  3. vocabs: FOAF, Schema, DBpedia 
Ontology ... 4. URI design #me ... 5. semantic errors, i.e. datatypes

Each one of them can cause a lot of interoperability issues. I would 
like to see an unambiguous,  mandatory /  DEFAULT / highly recommended, 
yet simple way for publishing WebIDs. Simply for these two reasons: 1. 
Users do not need to understand the concept, but can just follow the 
standard. 2. Less errors and heterogeneity in adoption.  This is the 
part that needs to scale, i.e. > 1 Billion WebIDs, if very successful. A 
good validator would be helpful. We made an abandon prototype here: 
http://wof.tools.dbpedia.org/validator   (We are moving away from 
recommending turtle towards JSON-LD, though).  It was abandoned, because 
we needed the WebID mainly for the Databus and then decided to provide 
WebIDs with the Databus.

Then if this part is clear and simple, advanced features can be added. I 
can totally see that wallet implementations (e.g. browser extensions, 
software holding the private key) can be burdened with more 
responsibility as this component needs to tackle TLS and security, as 
well, and developers can also be expected to understand concepts well. 
Also, there will not be so many.

I also agree that this is distracting from the core objective of the 
standard, but in the end, it will be the thing that decides about 
adoption and producing a working system technically and thus achieving 
the core objective.

--- Sebastian

Received on Friday, 21 January 2022 16:30:05 UTC