Re: WebID default serialization for WebID 2.x

On 1/21/22 11:29 AM, Sebastian Hellmann wrote:
> 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. 


Hi Sebastian,

Yes, but it starts by moving beyond WebID as the focal point. Why? 
Because its problems will not go away anytime soon -- which is why we 
(OpenLink) have moved on to NetID as a new moniker for a simpler and 
much more practical approach to Identity Authenticity.


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


Personally, this can be reduced to a Hyperlink to Entity Denotation and 
a JSON document Entity Description re Web Developers since they are the 
one's that are actually going to build apps.

Builders win in the game of software.


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


Wallet integration and interop matters are solved by what I suggest above.


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


It doesn't distract, in fact, it hones into the fundamental issue:

Meet the key audience where they are at.

Key Audience:

Web App Developers, they are the ones that build stuff. As engineers, 
their basic instinct is to make stuff using tools that are simple and 
practical.

Today, JSON is everywhere in the developer realm which makes fighting it 
futile and distracting. RDF and JSON are very compatible, as we've 
demonstrated in our Structured Data Sniffer Browser Extension etc..

Conclusion:

1. Move to NetID from WebID re notion of Identity Authenticity 
Infrastructure that's adapted by Web Developers

2. Ditto regarding associated Profile Docs


>
> --- Sebastian
>
>
>
>
>

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