Comments on ResourceShape 3,0 spec

[Ian Green1 <ian.green@uk.ibm.com>]

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.

"For all shapes
that "apply to" or describes an associated resource... "
--  typo "describes".

"whose oslc:valueShape
links to the constraining shape.." should this be "links from"?

"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"?

"the source is the subject [of] its "

Section 6
Is this section non-normative?

"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?

"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.


Typo: spelling of "arbitrary".

Section 6.2
Typo: "to [an] rdf:type T and " 

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?

Section 8.2
occurs: Suggest we introduce wording as per https://issues.oasis-open.org/browse/OSLCCORE-60.

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.

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.

[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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU