Re: Can Shapes always be Classes?

On 11/7/2014 21:46, Eric Prud'hommeaux wrote:
> I've been looking at messages on this list, e.g. 
> http://lists.w3.org/Archives/Public/public-rdf-shapes/2014Jul/att-0002/sotaspin-text.spin.ttl 
> This is an old message and maybe I should be looking at newer examples 
> but the implementation of Resource Shapes in SPIN 
> http://www.w3.org/mid/53D1FDF7.7040304@topquadrant.com doesn't show me 
> the SPIN proposal for oslc:valueShape . Settling the questions of 
> whether shapes should be separable from types requires some 
> examination for how the use cases met by OWL restrictions, 
> oslc:valueShape or ShExC valueReferences ("@<shapename>") can be met. 

The original oslc:valueShape design assumes that shapes are stand-alone 
entities. SPIN doesn't follow that philosophy and instead assumes that a 
shape is also a class. Therefore, the SPIN prototype of OSLC uses 
oslc:range, just like OWL uses rdfs:range or owl:allValuesFrom.

>> I would actually consider global domains/ranges as an anti-pattern:
>> all object-oriented systems allow the reuse of property names and
>> scope those properties relative to a class, not globally. schema.org
>> is a good example of that, and the problems of enforcing global
>> ranges/domains. I had given examples of how SPIN can represent
>> localized Resource Shapes and even owl:allValuesFrom using SPIN
> I didn't find the example of a spin template for owl:allValuesFrom,
> though I did find refs to it in replies to Karen and Axel.

You can basically use the SPIN OSLC implementation - substitute 
owl:allValuesFrom with oslc:range.

> I expect that anything that
> can be compiled to SPARQL can also be parameterized in a SPIN template
> to effectively execute that same SPARQL query (using arg variables
> bound by matching a particular OWL idiom).

Any number of SPARQL compilers could be conceived, including some that 
create completely new SPARQL query strings. So not every such potential 
compiler can be expressed from a static set of parameterized SPARQL 
queries. However, in practice these parameterized queries seem to work 
very well.

> I'm afraid I don't follow the reference to "localized Resource Shapes".
> Is this another way of capturing the spin:ContextSensitiveConstraint you
> sketched out in 0075?

Yeah, this was not a good term. I just meant the OO-like class 
attachment of constraints that SPIN uses.

> Adding contextual constraints to SPIN would allow it to meet many 
> clinical use cases where specific observations confer restrictions on 
> the result. 

See the sub-thread with my recent message at

http://lists.w3.org/Archives/Public/public-data-shapes-wg/2014Nov/0101.html

for which I am curious about your opinion. I remain convinced that the 
most relevant scenario for this technology is that constraints can be 
attached to classes (and resources have rdf:types), and the language 
design should be optimized for those cases, not for the exceptional 
cases. We should however try to accommodate those exceptional cases as 
good as reasonably possible, and I am trying to find ways to extend SPIN 
to cater for them.

Thanks,
Holger

Received on Saturday, 8 November 2014 06:38:28 UTC