Re: Comments on ResourceShape 3,0 spec

["Jim Amsden" <jamsden@us.ibm.com>]

Ian,
Great review, thanks. Comments embedded
below...

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 Ian Green1/UK/IBM
To:      
 OASIS <oslc-core@lists.oasis-open.org>
Cc:      
 Jim Amsden/Raleigh/IBM@IBMUS
Date:      
 02/12/2016 04:40 AM
Subject:    
   Comments on
ResourceShape 3,0 spec

---

comments on https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/resource-shape.html

as at svn 338.


Section 1
Paragraph beginning "It
is well-known..." the terminology is not quite right.  An ontology
is not something to be satisfied, and there are not "errors"
in the data but there can be inconsistencies.  The logics relating
to OWL can be used to reason about constraints - given logical _expression_
as inconsistency.  OWL DL is complete, for example, but its decision
procedure has unattractive :-) time complexity.  I think the shape
effort is an attempt to characterise constraints in an extra-logical setting
and one in which we have better computational characteristics. A reference
to that motivation would be useful (the SHACL page does indicate that compromises
have been made but it doesn't really state why).

I think we should simply state (as you do in S4) that
we want to have a way of describing resources - not sure that we need to
compare/contrast with the OWL/RDFS approaches. Use cases include a data-driven
query builder, for example.
<jra>I agree this could be worded
better how about:
RDFS and/or OWL are used to define OSLC
vocabularies which specify the terms (classes and properties) and their
semantic meaning. Vocabularies don't define constraints on what can be
asserted, rather they define the meaning of what was asserted, often through
the use of reasoners that introduce inferred assertions. However, there
are also situations where a vocabulary needs to be constrained in order
to be used in a specific context for a specific purpose. RDFS and OWL are
often not useful for this purpose as unless the vocabularies are carefully
designed, reasoners can introduce unintended assertions that are not consistent
with the specified purpose.
</jra>.

"For all shapes
that "apply to" or describes an associated resource... "
--  typo "describes".
<jra>Fixed</jra>

"whose oslc:valueShapelinks to the constraining shape.." should this be "links from"?
<jra>, or the resource may be the
object value of an rdf:Property whose applicable <a href=""
links to the constraining shape.</jra>

"A described resource is the resource whose RDF graph
is being described by a shape ".  Does this mean that a shape
describes an RDF graph?  Yet shape does not have a means to talk about
graphs.  Maybe this would be clearer as "... whose RDF graphs
are being described"?
<jra>I don't think shapes have anything
to do with RDF graphs. Should be:

A described resource is a resource that
is described by some shape.</jra>

"the source is the subject [of] its "
<jra>Fixed</jra>

Section 6
Is this section non-normative?
<jra>I market the Overview as informative.
However the other sections don't explicitly separate out normative clauses
in subsections like the other specs do, and doing so would require a fair
amount of refactoring of the document I didn't want to do in order to attempt
to preserve Arthur's original content as much as possible</jra>

"That
is, the intention is not that an OSLC implementation would reject a message
if it violated shape constraints, rather the intention is that implementations
do what is specified by an OSLC spec when they get data that conforms to
the shapes"    and the two preceding bullets - what does
this mean?
<jra>How about this and the two preceding
bullets are repaced by:
Specifically, shape constraints say how
OSLC clients and servers must behave if the resources satisfy the applicable
shape constraints, but they do not say what clients and servers may do
if the applicable constraints are not satisfied.
.</jra>


"The Shapes specification is based on a simple conceptual..."
this paragraph feels out of place in a spec - it's a bit soft.  In
particular, the final sentence "Although the Shapes specification
works well in practice, it cannot describe arbritary RDF graphs. "
leaves me wanting a positive statement about a class of problems where
it does work.

I'm not sure how much this document
progresses the cause of pinning down the meaning of resource shape.  I
worry it raises as many questions as it answers.  The idea of "association"
and "application" are introduced but it is not clear how participants
would know which SHOULDs apply and which do not, whether there is OR or
AND semantics, nor how a participant can discover which shapes are associated
with a given resource, something that seems impossible without some concept
of closure.
<jra>I get your point, but I'm not
sure what an appropriate action could be. We could re-write large portions
of this spec, pulling out specific paragraphs that should be marked as
specific normative clause sections. This was intended to be an incremental
improvement of shapes 2.0. But given the intended long-term investment
in shapes, in the face of SHACL, I thought we concluded that doing the
minimum would be enough for OSLC3. And I didn't want to risk making things
worse :-)

Is there a specific action you are recommending?</jra>

Typo: spelling of "arbitrary".
<jra>Fixed</jra>

Section 6.2
Typo: "to [an] rdf:type T and " 
<jra>Fixed</jra>

What does "error condition" mean in "If
no associated shape applies to a resource then this SHOULD normally
be interpreted as an error condition. "?  It's not clear what
actions can be taken (or should not be taken) when such a situation is
encountered.  Is behaviour unspecified?
<jra>This means that if shapes are
associated with a resource, but none are applicable  (because the
rdf:type doesn't match oslc:describes), then there is probably something
wrong with the data or the design of the shapes. Error condition is a general
term for that I guess.</jra>

Section 8.2
occurs: Suggest we introduce wording as per https://issues.oasis-open.org/browse/OSLCCORE-60.
<jra>Fixed, but we should probably
vote on this. If a client is expecting a single value, it could get more
than one and that could be breaking.</jra>

valueType: I've proposed that we include
xsd:date (see https://issues.oasis-open.org/browse/OSLCCORE-58)

Are we correct to exclude rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#langString"
from the allowed datatypes?  RDF literals have always confused me,
but my understanding is that rdf:langString and xsd:string are not the
same thing (eg one can distinguish them in a SPARQL query).  Excluding
rdf:langString means that language-tagged literals would not be allowed;
 clearly this is not what we want - so either I'm wrong or we need
to change the spec.
<jra>I'm wondering if rdf:XMLLiteral
was intended to address language tags on xsd:string, and there was specific
intent to avoid rdf:langString. But I don't know.</jra>

Have we considered relaxing this valueType constraint
entirely - any type goes?  Why is there a narrow set of datatypes?
 If a domain application wanted to extend permitted datatypes its
not clear that this is "allowed" (Jad raises a similar question
in [1]) but what is the reason for Core to start off with such a limited
set?  My guess would be that there will be a tendency for an implementation
to deal with the datatypes we list in Core spec, and to ignore what any
domain spec may or may not say.  Unless there is a good reason to
have a closed (by Core) set of datatypes, I would support that the spec
leave this open, perhaps with a REQUIRED minimal set which agrees with
2.0, in the interests of backward compatibility.

<jra>I don't know the history of this.
I suspect it was to limit what servers needed to implement. Adding new
primitive types could break existing OSLC 2 clients if the values were
used on OSLC2 vocabulary properties. For example if an OSLC3 server happened
to set a dcterm:created property to an xsd:date instead of xsd:dateTime,
that would break an OSLC2 client since all components of dateTime are required
and an xsd:date wouldn't therefore parse as a dateTime.

My feeling is that unless there is a specific
use case and/or requirement that demands change her, we should be conservative
and leave it compatible with OSLC 2.0. </jra>

[1] https://lists.oasis-open.org/archives/oslc-core/201602/msg00047.html

best wishes,
    -ian

ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM