Re: Why are RDF, RDFS & OWL not returning human-friendly versions?

Agree that the foundational namespaces of RDF should have browser-friendly rendering (if anything just to point people to the right spec).

It's certainly possible, see for instance https://www.w3.org/ns/prov#Activity  (oh no, a resolvable #reference!)

--
Stian Soiland-Reyes
The University of Manchester
https://www.esciencelab.org.uk/
https://orcid.org/0000-0001-9842-9718

On 3 Apr 2019 07:54, Niklas Petersen <petersen@cs.uni-bonn.de> wrote:

Hi,

thanks for the technical explanation & ideas. I also saw that my browser (Firefox 66.0.2) was sending more than I asked for. But I did not want to ask a too technical question.

The question is, how do we proceed?
Is it ok as it is? Should it be changed? Who should be approached to change it? I was hoping that maybe some people who could change it would respond to my message, but that did not happen.

I can send a mail via the contact/support of the W3C, but I am not sure how successful I will be.

It is my opinion that having a human-friendly landing page to the URIs fits very well fit into the "EasierRDF" movement. How many of the "33% developers" are we loosing each single day where all they get back is some ugly source code?


Best regards,
Niklas

On 31.03.19 9:34 nachm., Stephen D. Williams wrote:

While mimetypes are a good starting point, there can always be a need for more granular options.

Query parameters are one good, easy to use option used in other circumstances for this kind of thing.  For instance:

https://unpkg.com/

>
>       Query Parameters
>
> |?meta|
>     Return metadata about any file in a package as JSON (e.g.|/any/file?meta|)
> |?module|
>     Expands all “bare” |import| specifiers <https://html.spec.whatwg.org/multipage/webappapis.html#resolve-a-module-specifier> in
>     JavaScript modules to unpkg URLs. This feature is /very experimental/
>

Stephen



On 3/31/19 4:02 AM, Richard Light wrote:
>
> Niklas,
>
> I was bitten by this issue when testing content negotiation outcomes. The issue is that your browser is not an innocent bystander
> in this HTTP transaction: it will have provided a requested set of response formats (and not just 'text/html') which will have an
> impact on what is returned.  And different browsers have different default settings (which you as their user can alter).
>
> Richard
>
> On 31/03/2019 06:59, Niklas Petersen wrote:
>> Hi,
>>
>> visiting via a browser (text/html) the URIs of RDF, RDFS and OWL returns the turtle serialization of them. Would it not be better
>> to provide a more human-friendly version (.html)?
>>
>> http://www.w3.org/1999/02/22-rdf-syntax-ns#
>>     -> ? (probably to RDFS :/)
>>
>> http://www.w3.org/2002/07/owl#
>>     -> https://www.w3.org/TR/owl2-overview/
>>
>> http://www.w3.org/2000/01/rdf-schema#
>>     -> https://www.w3.org/TR/rdf-schema/
>>
>>
>> Best regards,
>> Niklas
>>
>>
>> .
>>
> --
> *Richard Light*


--
Stephen D. Williams sdw@lig.net<mailto:sdw@lig.net?Subject=Re%3A%20Why%20are%20RDF%2C%20RDFS%20%26%20OWL%20not%20returning%20human-friendly%20versions%3F&In-Reply-To=%3C841fcd97-c404-c456-cf79-9520cc6f90c4%40lig.net%3E&References=%3C841fcd97-c404-c456-cf79-9520cc6f90c4%40lig.net%3E> stephendwilliams@gmail.com<mailto:stephendwilliams@gmail.com?Subject=Re%3A%20Why%20are%20RDF%2C%20RDFS%20%26%20OWL%20not%20returning%20human-friendly%20versions%3F&In-Reply-To=%3C841fcd97-c404-c456-cf79-9520cc6f90c4%40lig.net%3E&References=%3C841fcd97-c404-c456-cf79-9520cc6f90c4%40lig.net%3E>
V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407
Hangouts:stephendwilliams@gmail.com<mailto:stephendwilliams@gmail.com?Subject=Re%3A%20Why%20are%20RDF%2C%20RDFS%20%26%20OWL%20not%20returning%20human-friendly%20versions%3F&In-Reply-To=%3C841fcd97-c404-c456-cf79-9520cc6f90c4%40lig.net%3E&References=%3C841fcd97-c404-c456-cf79-9520cc6f90c4%40lig.net%3E> AIM:sdw Skype:StephenDWilliams
Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer
LinkedIn: http://sdw.st/in Resume: http://sdw.st/resume

Received on Wednesday, 3 April 2019 10:55:22 UTC