- From: Irene Polikoff <irene@topquadrant.com>
- Date: Tue, 22 Jul 2014 09:56:22 -0400
- To: "'Dam, Jesse van'" <jesse.vandam@wur.nl>, "'Antoine Isaac'" <aisaac@few.vu.nl>, <public-rdf-shapes@w3.org>
Jesse, If the goal is to make it as easy as possible for the business (none computer science) users to define constraints, in my experience, business users are most comfortable using some form of controlled English (or their own native language). Manchester OWL syntax provides some of this. SPIN templates provide this in a comprehensive and extensible way. This requirement is one reason why a proposal based on SPIN should include a set of standard templates. In cases where unique business requirements don't fit the standard set, implementers could extend it with the implementation specific templates. We can confirm that this approach works because we have business users successfully using SPIN templates to define constraints with little to no prior training. For an example of how this looks like, here are two screenshots - one for selecting a template http://download.topquadrant.com/evn/44doc/img/ug131.png and a second one for an example of filling it out http://www.topquadrant.com/temp/ug350.png . Regards, Irene -----Original Message----- From: Dam, Jesse van [mailto:jesse.vandam@wur.nl] Sent: Tuesday, July 22, 2014 6:20 AM To: Antoine Isaac; public-rdf-shapes@w3.org Subject: RE: in between position Hi, I fully agree with you, the point given by Paul is exactly the problem I had also. I really like the last suggestions given by Holger and Simon and we should continue on that (extra) path. It similar to what I was suggesting a little bit earlier in discussions. The things suggested are exactly does things which I am missing at the moment, especially if I try to train none computer science users. However I think we should keep this in working group of SHEX or at least we have to keep this discussing with the same group of people on this topic. Together we can make something better. One extra thing I think we should take into consideration when we want to make something simple it should be is oriented on the 'shape' properties(same as in OO languages) instead off shared properties(what OWL has). The result file(RDF) however should be direct (one or set of SPIN rule(s)) translatable to OWL-ICV and backward(only for the forward translated files, not for any OWL file). Translation to OWL will exclude the items that are only encodable in SPIN. The result file should be (or mappable to) a file that can be, together with the default rules defined in the SPIN Constrain Profile, validated with a SPIN engine. So the last part is basically (similar to) what you suggested. Note that the shape property oriented approach is a not a good idea if you would like to define a full powered(using all features) OWL file. I think/agree that the SHEX syntax (whatever it will become) should be standardized, but should not be required for an implementation. The same situation as it is now for Manchester Syntax in OWL def. Further more I think its important that we first solve the discussion on whether to detach or attach a schema/shape form the type. Resource shapes uses a detached mode(if I am correct). For SHEX no definite decision has been taken. When having a link to OWL it has to be attached(I think I could be wrong). I think most people would prefer to attach the shape to the type, however I think its good to think about the other option and find some good reason for not doing that and write these down. Jesse van Dam ________________________________________ Van: Antoine Isaac [aisaac@few.vu.nl] Verzonden: dinsdag 22 juli 2014 10:12 Aan: public-rdf-shapes@w3.org Onderwerp: Re: in between position Dear all, The discussion is really interesting, but I'm afraid grounded on sand and quite a waste of time now. As long as the cases for which we want RDF validation / shape checking are not further documented/formalized, firing examples by email will be a very stimulating game, but we won't be able to use them to disqualify either ShEx or SPIN or any other. Or to convince their creators to update them, if that's the best strategy. I imagine things will be quite different once there appears in a formal Group Note some requirements that are super-hard to tackle for ShEx or SPIN... I found Holger's last contrib to be especially interesting in fact. If someone like him thinks that an answer to the current draft charter [1] is: "oh, we could also make a group around SPIN", then it is indeed that there is something fishy with the current charter. We should create a technology-agnostic WG here. If the discussion demonstrates there's not enough consensus for a specific technology, consensus needs to be built. Personally I thought the current charter was neutral enough, and its focus on use case and requirements strong enough to warrant bias towards a given technology. Especially the word 'shapes' was not ShEx-binding, as it not used only by ShEx. But well, the group could also be titled with "constraints" instead of "shapes". And let the notion of shapes re-emerge through requirements, if it's indeed a relevant one (I believe it is, but well...). By the way I believe the charter could be a bit stronger on the OWL side. If there's a new standard for constraint checking, the group should have identified when users should use OWL, and when they should use the new standard. It might be just a matter of pointing to some existing papers on the topic. Best, Antoine [1] http://www.w3.org/2014/data-shapes/charter On 7/22/14 9:13 AM, Paul wrote: > Hi, > > As a SPIN and ICV user myself, I have no objections in standardising nor SPIN nor a closed world semantics OWL. > I have no opinions yet on ShEx since not studied. > > But what we as implementation partner encounter doing jobs (mainly linked data in the government domain) is that both SPIN and ICV are very difficult to sell. > The reasons might be different (perceived as difficult, overloading the system, OWL being already closed in the minds of people). > > So if there would come along a constraint language death simple (with escape route to SPARQL) that would get my vote also. > > > Paul > > > Kind Regards, > Paul Hermans > > > > >
Received on Tuesday, 22 July 2014 13:57:00 UTC