- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Mon, 01 Jun 2015 05:47:59 -0700
- To: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/31/2015 03:53 PM, Holger Knublauch wrote: > On 5/31/2015 22:47, Peter F. Patel-Schneider wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 05/31/2015 12:15 AM, Simon.Cox@csiro.au wrote: >>>> In general I believe we have an immense opportunity here to create >>>> something that could propel Semantic Technology into much more >>>> mainstream use cases, as a schema language for JavaScript >>>> applications, and servers using JSON for data exchange and >>>> interface definitions. >>> JavaScript also covers additional use cases that cannot be expressed >>> in SPARQL. >> Which use cases are these? > > > Karen's group had presented specific requirements to check whether > certain URLs are resolvable and produce certain response headers. > It's easy to come up with other ideas, e.g. checking the current > exchange rate of a currency via a web service, complex string or math > operations - anything that goes beyond the hard-coded standard > functionality of SPARQL engines. There are lots of things that one might want to do. There are even lots of things that one might want to do with a constraint engine. There are probably even lots of things that one might want to do SHACL. That doesn't make them use cases. At best, the last are potential use cases for SHACL. So maybe the ability to do something on the web is a potential use case for SHACL. It turns out that this has recently turned into an approved use case, S40 on the wiki. Can this be done in JavaScript? I don't know. Can this be done in SPARQL? I think that this depends on what parts of SPARQL can be used in SHACL. I don't think that SPARQL queries can do this without using an extension function. > The answer to your question should be obvious. It's impossible to > enumerate all these use cases because we cannot anticipate what > real-world users will do with SHACL. Many of them are simply > application-specific or API specific (like in the case of OSLC). The > fact that we didn't record all these use cases as user stories is not a > reason to exclude JavaScript support - it only shows that we were > conservative and focused on the traditional home turf of the WG members. > I urge the WG to look outside of our little worlds and embrace this > opportunity. Obviously not every SHACL engine would have to support all > of these features, but we already have this situation with the Core vs > SPARQL divide. > Holger peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVbFR/AAoJECjN6+QThfjzY9sH/37K0I4S4+Su++9IaVvCZCeX lmdmD9G3j2WhrlB/SMY0RFHyklwitXx4nQRjtwiHFWfJrEs6H/TN8OzfsD+8jrXs kjTpl2Owa7XMIUVYtmtvKYdCQdu5FSfSs5JF9i9tvrFez8GVzT2G4MgJt+aIQPhT MBYsc6SGzcY6e+WsKVRzCl05X3YrRQ/kmcfTNlkg2BpdEeiSeQazeO50OwyPTYwF dsjy27Ci5tyqa6BW+athKkNcVMayFOm6/WDKNtJ5TeNM5YHv3cDU3Gf23z//vlIN ItzeswF7bXw1zExIcmC2Btahcni1N00bGsDkxmeogBUV7B/CUS0/fM5AYIV4iDs= =dFgw -----END PGP SIGNATURE-----
Received on Monday, 1 June 2015 12:48:36 UTC