- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 07 Feb 2015 10:13:15 +1000
- To: public-data-shapes-wg@w3.org
On 2/7/15 12:34 AM, Eric Prud'hommeaux wrote: > * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2015-02-06 06:11-0800] >> The document is getting a bit better, but it is still very rough. >> >> A big problem is the example. In situations where objects have types it is >> natural to use these types to control the constraints, and even to drive the >> entire modelling process. In the example, what makes an object an issue? >> Is it an rdf:type link to ex:Issue, or is it two property-value pairs of the >> right form? I think that if you want to introduce shapes unrelated to >> classes then you cannot have classes that mirror the shapes. Like it or >> not, rdf:type is more equal than other properties. > I don't see this linkage in primers for XML Schema, JSON Schema, Relax > NG, Schematron, XML documents often have pointers to a DTD or schema. One of the strengths of RDF-based systems is that you can build applications that dynamically adjust their behavior depending on the data that they get (dynamic input forms, rules etc). For that reason, it is a good practice to have data that is self-describing. > but oh well, I've added an explicit statement: > [[ > The mechanism by which the instance data is associated with, or > validated against the a shape is not described as this point. > > <span class="todo">This WG is expected to define ways to link instance > data to shapes, e.g. instance-shape, class-to-shape, > query-endpoint-to-shape, etc. This document may include examples of > such linkages.</span> Just having a vague notion of linkage with "examples" will not be acceptable to us. The spec needs to clearly define the minimum rules, and we need to deliver test cases. If we continue with the currently established practice, then following the rdf:type triple is an obvious starting point. Other platforms such as OSLC may define additional entry points, and may also ignore the rdf:type triple for certain tasks. But if we stay too vague, we throw out the baby with the bathwater, and (unnecessarily) sacrifice interoperability. Holger
Received on Saturday, 7 February 2015 00:13:48 UTC