- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Fri, 1 Jan 2016 06:44:49 -0800
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: Jose Emilio Labra Gayo <jelabra@gmail.com>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
[Lots of stuff removed.] On 01/01/2016 05:50 AM, Eric Prud'hommeaux wrote: >> > The use case as previously described had rdf:type information for every box in >> > the diagram. Changing this important feature of the use case is not >> > acceptable. Yes, rdf:type links are not required for every node in an RDF >> > graph, but if your use case had them then they need to be retained. > This goes beyond whether rdf:type arcs are required for every node. In > order to use rdf:type arcs to target validation, we need to know that > some type arcs *uniquely* identify the nodes of interest (unless you > want to sort through arbitrary numbers of irrelevent validation > failures). > > Note that XML schema provides one way for nodes to be associated with > schema types, and Relax NG, provides, iirc, zero. Much of the use of > schema languages entails some external association between nodes and > candidate types. For instance, WSDL associates a schema type with a > node in a document in a protocol exchange. This is used in a few ways: > > 1 documentation - what do the messages have to look like > > 2 validation - WSDL applications root around in the SOAP envelope to > find the nodes of interest and test them against the schema types. > > 3 code generation - WSDL tools generate stub code based on the schema > types. This code is generally used within some framework which does > the rooting around in SOAP envelopes for you. > > > Given that it is important to be able to trigger validation by other > means than type arcs, how do you suggest that be introduced? Is it important to be able to trigger validation by other means than type arcs? I don't see that the submission. Well,actually the submission doesn't appear to talk about triggering validation at all. > > 1 a little explanatory text to the effect of "The original > representation of the web index included type arcs on every > node. This is not the case for RDF data in general so we are > modifying the use case to illustrate how validation occurs without > discriminating type arcs." > > 2 abandon the web index use case and cook up something much less > documented. > > IMO, 1 seems much more satisfactory to readers in general. I disagree, particularly given the thrust of the submission. Given that the paper appears to be about how suitable ShEx is for linked data portals, the ideal would be to show this with actual use cases. Features of ShEx that go beyond the actual use cases could be covered in a separate section. If something other than actual use cases is being employed it seems to me to be better to make up something and show that this something is illustrative of actual use cases. Using a modified use case just looks like the modifications were added only because they can be handled by the technology at hand. peter
Received on Friday, 1 January 2016 14:45:34 UTC