- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 08 Apr 2015 17:49:18 -0700
- To: Irene Polikoff <irene@topquadrant.com>, Holger Knublauch <holger@topquadrant.com>
- CC: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, at least we have a proposal for an extension mechanism. Whether it is something that the WG will endorse and whether it is elegant are less clear. peter On 04/08/2015 05:21 PM, Irene Polikoff wrote: > I think there are complex use cases that must be supported. And I think > that it is challenging to design a simple enough high level language > constructs for complex use cases. > > With this, there is a tension between the desire to have a 'simple high > level language' and requirements for complex constraints. However, we > have an elegant extension capability which resolves the tension. We don't > need to predefine all the high level constructs that would cover the > variety of complex possibilities. We can be agile and cover in the > prebuilt high level expressions the most obvious and straightforward > things. Let other things emerge over time. > > I see this process as similar to software releases - there is always a > seductive desire to try to cover more and more in the release 1. Everyone > has their own favorite requirement, some simple, some harder and the > release gets pushed back farther and farther . To avoid such syndrome , > one must be disciplined and committed to "curbing the appetites" - get > the product out there, get it used, get the feedback and move forward. To > me this seems as the much preferable way forward since we already have a > way to address all complex requirements. > > Irene > > Sent from my iPhone > >> On Apr 8, 2015, at 6:02 PM, Holger Knublauch <holger@topquadrant.com> >> wrote: >> >> Hi Karen, >> >> I agree with your general sentiment. But I did not reject paths; I did >> suggest them as requirement myself [1,2]. Paths are already covered by >> SPARQL. So the only question here was whether paths should be part of >> the high-level language, in addition to SPARQL. >> >> Holger >> >> [1] >> https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Transit ive_Traversal_of_Properties >> >> [2] https://www.w3.org/2014/data-shapes/wiki/Requirements#Properties_Used_in_Inver se_Direction >> >> >>> On 4/9/2015 7:35, Karen Coyle wrote: >>> >>> >>>> On 4/8/15 1:03 PM, Holger Knublauch wrote: I am against the >>>> splitting of documents if this risks a situation in which the Core >>>> gets standardized while the SPARQL bits do not get standardized. >>>> Only in that situation my point is that the SHACL core language >>>> alone would be a step backwards in the evolution of the semantic >>>> web space, because it will cause a fragmentation of the market >>>> without adding much that OWL didn't already have. >>> >>> I think this depends on how we define core. I think of core as being >>> the functions that will serve the highest percentage of needs - the >>> famed 80% of uses. I don't think that means that those needs are >>> simpler or have a simpler solution or do not use SPARQL. >>> >>> This means that we should develop standard solutions to that 80% if >>> we can. I prefer that we identify that core and get clarity on it >>> before rejecting features (as in the discussion of paths) for >>> implementation reasons. That doesn't mean that everything we would >>> like to have as core will be provided in the standard; I just think >>> that we musn't leap into implementation questions before we settle >>> the "what do we want" question -- do the "what" then the "how", then >>> iterate until we have the best possible solution. >>> >>> kc >> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVJcyOAAoJECjN6+QThfjztlEH/RwOtASxhNEjhJi5NpfpXZhT BzHxDfo5nTxHjBddPRQ8fwuDuVNumBjQnHY/QnzXGuG3M5coqkGW8/nwuw3D204U tYx6WCsX4bUL9up7fA2rL8TkTrHLG71tGrOgc9HeiPZ5GX86+EgXhjvjfxyr7tsx KIgNi9L+55OaFvtn2llvp7zsQaCKZWN5VIppzXzjH02KzmUhucQ9VSFvEOhYt06B 2MP0nnob3Na9bkdlnaqyNDWHZJfUucLGOofdiM3GqY4wVev0HtTIz+kGhZqR/JZ5 KGkrXTZbiMhmfj9MO8qgEP9uE1akKgBIOEyY9JgHgT2v2JgamIogWtkRGKbQ9SI= =BHGL -----END PGP SIGNATURE-----
Received on Thursday, 9 April 2015 00:49:49 UTC