- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Tue, 25 Nov 2014 17:14:04 -0500
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-data-shapes-wg@w3.org
* Holger Knublauch <holger@topquadrant.com> [2014-11-19 22:36+1000] > > On 11/19/14, 9:14 PM, Eric Prud'hommeaux wrote: > > > >This is a critical architectural issue. If we weave mutually > >inconsistent data into the shapes architecture, we over-constrain its > >use in ways that will have long-term consequences. > > The same argument can be applied in the reverse direction: if we > separate shapes from classes, we over-complicate its use from the > data models that exist in parallel. We can attach shapes to types when it's appropriate. Resource shapes defines ways to link instances and interfaces to shapes. <http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#instanceShape> These are analogous to the reference of XML Schema from a processing directive or from WSDL. It's reasonable to add rs:typeShape to meet the use cases to which you refer. > For the majority of use cases > you would end up with Shape objects that are mirroring classes, I disagree that the majority of shapes would be global invariants. But regardless, the fact that we don't want to write off the other use cases implies that we must not require a model which forces one to retract one schema when looking at another when both should be associated with particular interfaces. > while it would indeed be more consistent (and easier to look up from > a Linked Data perspective) if they were as aligned as possible. In > ShExC you furthermore end up with two different syntaxes for > virtually the same entities - one is triple-based and the other > based on regular expressions. > > Having said this, please take a look at my proposal to merge > stand-alone Shapes into SPIN structures, based on the introduction > of just a single helper function, which spawns off recursive > constraint checking engines. I believe this may lead to a solution > that we can all live with, and that is still easy enough to explain > and consistent to implement. > > The rest then becomes syntactic sugar. > > Holger > -- -ericP office: +1.617.599.3509 mobile: +33.6.80.80.35.59 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution. There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper.
Received on Tuesday, 25 November 2014 22:14:08 UTC