- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 21 Jan 2022 09:34:37 -0500
- To: public-webid@w3.org
- Message-ID: <46bb0a6a-8ad6-8869-58be-658833735d9a@openlinksw.com>
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 -- 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 21 January 2022 14:34:52 UTC