FW: ShEx, profile definitions & conneg

A email from Gregg Kellogg of the JSON-LD CG with some points about Conneg by Profile.

From: Gregg Kellogg <gregg@greggkellogg.net>
Sent: Monday, 14 January 2019 5:43 AM
To: Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au>
Cc: Eric Prud'hommeaux <eric@w3.org>; Rob Atkinson <rob@metalinkage.com.au>
Subject: Re: ShEx, profile definitions & conneg

On Jan 13, 2019, at 2:39 AM, Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au<mailto:Nicholas.Car@csiro.au>> wrote:

Hi Eric & Gregg,

You may both know about the profiling work done in the Dataset eXchange WG and have seen the requests to review the FPWD of the Profiles Ontology & the Conneg by Profile docs ([1] & [2]) or even the email I just sent to the ShEx CG but I want to hassle you both once again all the same. The reason is that while we have a few people familiar with constraint languages in the DXWG, we don’t have participation by the ShEx or SHACL core so we may not be across all the ins and outs of these initiatives.

Hi Nick, sorry, I missed any previous emails; I haven’t been involved with ShEx for a while due to life issues and over-commitment to the JSON-LD WG work.


 You will no doubt see that the Profiles Ont and Conneg specs are pretty basic but, nevertheless, potentially powerful given that, due to their simplicity and as we see it great need, they might be adopted widely. I and DXWG are very keen to know what you as constraint language authors think of the proposals and how this may help, or hinder, effective use of ShEx etc.

I can imagine that future profiles of things, defined using Profiles Ont, might have a series of standard components – guidancedocuments, full constraints ShEx or SHACL files, component equivalents – ShEx & SHACL files, non-equivalent partial constraints files etc. and that, if someone maintains and grows a vocabulary of parts’ roles, we may see something more powerful in the further than the bare ontology spec suggests and consistency will increase. What do you think? Could the W3C maintain or at least support others to maintain such a vocab?

The profile work is interesting, and this is well-trod ground. I presume Karen Coyle has been involved in some way? (I didn’t see that she was a WG member). I recall discussing ways in which a profile might be programmatically transformed into ShEX or SHACL that could then be used against a document purporting to follow a profile for validation.


Also, we haven’t got all the answers yet for the Conneg by Profile document and there we butt up against things like JSON-LD profiles (Rob Sanderson’s in the WG to help here) but I think we are going a bit further than JSON-LD profiling with actually hinting at expected content given the potential for a URI-defined profile used in conneg to indicate what is required for conformance (the points above).

The content-negotiation document relates to work in the JSON-LD WG, for example the discussion in our IANA Considerations section [3] on the use of the profile media-type parameter for specifying the form of JSON-LD requested of a server.

We had a section on the use of the Link header for providing the URL of a frame or context to use for supporting the requested profile (e.g., the “framed” profile could be provided with a default frame, but it would be good to have a way of specifying a specific frame to be used). We yanked this out, and may move to a best-practices document, as it was not something we felt we were chartered to do. There certainly is a conversation on the difference between the profile parameter, and Accept-Profile header, which looks like a good direction for you, IMHO. It would be useful to be able to content-negotiate over this; an opaque frame URL is not helpful, as it would be challenging to know what it meant if it wasn’t registered. We came down on the use of the profile parameter to specify registered profiles, that may imply specific contexts or frames to be used as part of the profile specification. Of course, the profile URI could, itself, be used to returned the context or frame.

Thanks in advance for any thoughts! See you at the ESWC in June in Slovenia perhaps?

I’m afraid I have no plans to attend with no budget to support such travel.

Gregg

[3] https://w3c.github.io/json-ld-syntax/#iana-considerations



Thanks,

Nick


[1] https://w3c.github.io/dxwg/profilesont/

[2] https://w3c.github.io/dxwg/conneg-by-ap/


Nicholas Car
Senior Experimental Scientist
CSIRO Land & Water
41 Boggo Road, Dutton Park, QLD 4102, Australia
E nicholas.car@csiro.au<mailto:nicholas.car@csiro.au> M 0477 560 177 P 07 3833 5632

Received on Tuesday, 15 January 2019 21:17:00 UTC