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

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

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