OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: Comments on ResourceShape 3,0 spec

Great review, thanks. Comments embedded below...

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data

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.

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

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

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.

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

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?
<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.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]