- 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