- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Wed, 19 Nov 2014 04:32:42 -0500
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-data-shapes-wg@w3.org
* Holger Knublauch <holger@topquadrant.com> [2014-11-19 10:55+1000]
> On 11/19/2014 9:47, Eric Prud'hommeaux wrote:
> >* Holger Knublauch <holger@topquadrant.com> [2014-11-06 09:38+1000]
> >>I think it's encouraging to read suggestions on how we could merge
> >>ideas from the various proposals, e.g. extend SPIN to make the
> >>scenario below easier to represent. This is always a possibility.
> >>
> >>Thanks for providing a specific example, which makes our discussion
> >>more focused. I do believe that the example below can be expressed
> >>with the existing SPIN spec via something like
> >>
> >>:Issue
> >> spin:constraint [
> >> a sp:Ask ;
> >> sp:text """
> >> # The assignee must have an mbox
> >> ASK {
> >> ?this :assignedTo ?assignee .
> >> FILTER NOT EXIST { ?assignee foaf:mbox ?any }
> >multiplied out for cardinality over :submittedBy:{given,family},
> >status=unassigned | (status=assigned &&
> >assignedTo/{givenName,familyName,mbox}), etc. gave me the 107 lines of
> >SPARQL at the bottom of this message.
>
> Instead of all these nested SELECTS to compute cardinalities, in
> SPIN you would just use the function spl:objectCount(?subject,
> ?predicate). Any number of similar helper functions can be defined
> to make the queries significantly shorter.
>
> So hypothetically assuming someone would really want to mix
> everything into a single query, here is how your example could be
> expressed in SPIN:
>
> ASK {
> FILTER shape:constrain(?this, :name, rdfs:Literal, 1, 1) .
>
> ?this :submittedBy ?submitter .
> FILTER shape:constrain(?submitter, foaf:givenName, rdf:Literal, 1, 1) .
> FILTER shape:constrain(?submitter, foaf:familyName, rdf:Literal,
> 0, 1) .
>
> ?this :status ?status .
> {
> FILTER (?status = :assigned) .
> ?this :assignedTo ?assignee .
> FILTER shape:constrain(?assignee, foaf:givenName,
> rdf:Literal, 1, 1) .
> FILTER shape:constrain(?assignee, foaf:familyName,
> rdf:Literal, 1, 1) .
> FILTER shape:constrain(?assignee, foaf:mbox, rdfs:Resource,
> 1, 1) .
> }
> UNION {
> FILTER (?status = :unassigned || ?status = :unknown) .
> }
>
> FILTER shape:constrain(?this, :related, rdfs:Literal, 0, -1) .
> }
>
> where shape:constrain would be a helper function which checks that
> all values of a given subject/predicate combination are of a given
> type, and have given min/max cardinalities.
>
> With this helper function, the SPARQL syntax has the same number of
> lines like your ShExC snippet. (There could probably even be a
> converter that takes a controlled subset of SPARQL and rewrites it
> into ShExC and vice versa - the focus of ShEx is on combinations of
> cardinality and range constraints, and not much else).
With the shape:constraint extension that you define, that would be
possible in many cases.
> Eric, I would encourage you now to do the same that I am doing here
> for you: please show us how the various other examples in the User
> Stories section are expressed in ShEx. Let's please level the
> playing field here, and not just look at the examples that motivated
> the creation of ShEx. It is quite easy to make a point if you can
> define the requirements and select the examples yourself. There is
> no doubt that ShEx is good for a certain class of use cases.
Digging back in the thread, you asked the question "Can Shapes always
be Classes?" and I provided examples of context-sensitive constraints
in OWL and Resource Shapes that can't be met by using type arcs in the
instance data as shape identifiers. I have frequently used ShExC as a
shorthand way to write the Resource Shapes (some find it quicker to
read) but I can make an effort to include both.
> Once you look at other examples, you may discover that ShEx is not
> expressive enough for many other real-world use cases. Nor do I
> believe that those context-sensitive scenarios like the artificial
> bug tracker example are representative of the majority of use cases.
>
> My point in this discussion is that with ShEx we would basically
> create an alternative to SPARQL, and I do not see enough convincing
> arguments that would favor a completely new language over an already
> established one, especially if that new language lacks many other
> features that have already been shown to be needed in practice.
> SPARQL could certainly need syntactic sugar for our constraint use
> cases, and SPIN functions like the one above would be one way of
> achieving that without even requiring a change to SPARQL itself.
>
> I would also welcome other people on this WG to join this discussion
> - I don't see why it always has to be me defending SPARQL :)
>
> >Any time you see a restriction in OWL you have an example of a
> >contextual constraint. OWL literature pretty much indoctrinates
> >for constraining general predicates for us in particular classes,
> >e.g. the pizza tutorial's :hasTopping. I've used many nested
> >property restrictions in the projects that I've worked on.
>
> That's fine, and can be expressed in SPARQL too.
You have proposed a template-driven form of SPIN that's similar to
Resource Shapes. It still needs a name, perhaps "Template-SPIN"?
Template-SPIN and ResourceShapes (and thus ShExC) both provide a
simple languaeg with reduced expressivity for:
execution by less powerful engines
generating user interfaces
communicating with programmers
various governance tasks, etc.
The issue is whether the core language can capture this common (and
encouraged) idiom of context-sensitive constraints. You have proposed
extensions to Template-SPIN which duplicate cardinality and type
restriction for one level of nesting. Resource Shapes is more
intuitive in that the grammar is recursive and permits the same
pattern for constraints regardless of the depth, as seen in my
previous example:
[[
<http://ex.example/x#NewIssueShape> a rs:ResourceShape ;
...
rs:property [
rs:name "submittedBy" ;
rs:propertyDefinition :submittedBy ;
rs:valueShape x:SubmitterShape ;
rs:occurs rs:Exactly-one ;
] ;
...
<http://ex.example/x#SubmitterShape> a rs:ResourceShape ;
rs:property [
rs:name "givenName" ;
rs:propertyDefinition foaf:givenName ;
rs:valueType shex:Literal ;
rs:occurs rs:Exactly-one ;
] ;
rs:property [
rs:name "familyName" ;
rs:propertyDefinition foaf:familyName ;
rs:valueType shex:Literal ;
rs:occurs rs:Zero-or-one ;
] ;
.
]]
or for example of cured patients:
:CuredPatientShape {
core:cureIndication {
core:hasIntervention (:KidneyTransplant :HeartTransplant),
core:hasOutcomeAssessment {
core:hasResultValue (:ImprovedToNormal)
}+
}
}
≡
:CuredPatientShape a rs:ResourceShape ;
rs:property [
rs:propertDefinition core:cureIndication ;
rs:valueShape [
a rs:ResourceShape ;
rs:property [
rs:propertDefinition core:hasIntervention ;
rs:allowedValue :KidneyTransplant , :HeartTransplant ;
rs:occurs rs:Exactly-one
], [
rs:propertDefinition core:hasOutcomeAssessment ;
rs:valueShape [
a rs:ResourceShape ;
rs:property [
rs:propertDefinition core:hasResultValue ;
rs:allowedValue :ImprovedToNormal ;
rs:occurs rs:Exactly-one
]
] ;
rs:occurs rs:One-or-more ;
]
] ;
rs:occurs rs:Exactly-one ;
] .
> Regards,
> Holger
>
>
--
-ericP
office: +1.617.599.3509
mobile: +33.6.80.80.35.59
(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Received on Wednesday, 19 November 2014 09:32:46 UTC