RE: in between position

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