- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Wed, 3 Dec 2014 17:18:19 -0500
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-data-shapes-wg@w3.org
* Holger Knublauch <holger@topquadrant.com> [2014-12-03 10:53+1000] > If I understand the ticket's purpose correctly, then there are two > dimensions > > a) how to store, reference and share constraint definitions in > graphs (Peter addressed that) > b) how to instruct an engine so that it knows which checks to perform > > On b) I believe there is a wide agreement that associating "shapes" > with classes makes a lot of sense, and I believe all proposed > mechanisms have some vocabulary for that purpose (in SPIN and OWL > this is simply relying on the rdf:type arcs). At the same time, > there are use cases where this association with classes is not the > only mechanism, and some resources need to be checked against > additional patterns in specific contexts. In Resource Shapes 2.0 > this is done (among others) via oslc:valueShape, and it sounds > straight-forward to define similar properties that can be submitted > as part of a constraint checking request. Resource Shapes 2.0 seems > to have oslc:instanceShape and oslc:resourceShape for that purpose. > I believe oslc:instanceShape is similar to rdf:type. [[ The oslc:instanceShape property is used to link any described resource with a shape resource that describes its contents. ]] — http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#instanceShape suggests to me that it connects an instance node to a shape, rather than a type to a shape. I propose we use the predicate shapes:typeShape until something better comes along. > oslc:resourceShape seems rather specific to the web service > architecture, and I am not sure how far the WG will reach in this > regard. I would argue the latter could be an OSLC specific extension > because it relies on concepts outside of our focus. > > At this stage I am not sure what is missing to resolve this ticket. > The ticket is about collecting all ways a shape can be associated > with a graph. Peter has enumerated some. I have written that the > rdf:type triples can be used. Who can elaborate on the other > mechanisms employed by ShEx and Resource Shapes, and clarify which > ones are proposed to be handled by the WG? For ShEx, we use command line arguments to say "validate node <N> in datatype <D> as shape <S>" and "find all shapes for every node in dataset <D>". See <https://github.com/labra/ShExcala/wiki> for an example. If we want properties for this, we can concoct something like shapes:startingNode and shapes:startingShape for the former case. For the latter, a schema is basically a closed set of shapes so we could enumerate shapes to check but maybe it's more reasonable to point to the schema. > Thanks, > Holger > > > On 12/3/2014 5:58, Peter F. Patel-Schneider wrote: > >On 11/18/2014 09:17 AM, RDF Data Shapes Working Group Issue > >Tracker wrote: > >>rdfdatashapestracker-ISSUE-3 (Shape association): How is a shape > >>associated with a graph? > >> > >>http://www.w3.org/2014/data-shapes/track/issues/3 > >> > >>Raised by: Arnaud Le Hors > >>On product: > >> > >>There has been quite a bit of discussion about how a shape is > >>associated with an instance graph. Some technologies rely on a > >>type but this isn't accepted by all as sufficient to address all > >>use cases. So, what are the ways a shape can be associated with > >>a graph? > > > > > >As far as I can see there are only a few potential mechanisms for > >associating some constraints with an RDF graph. (This is separate > >from determining which part of the RDF graph the constraint acts > >on, by the way.) > > > >1/ The constraint could be in the graph itself. > > > >2/ There could be an explicit connection between the graph and a > >source for the constraint. This would work something like > >owl:imports, but the source would not have to be an ontology > >document. The connection could also be indirect, e.g., the graph > >owl:imports an ontology document which is itself explicitly > >connected to a constraint document. > > > >3/ There could be an implicit connection between the graph and a > >source for the constraint. This could be something like "follow > >your nose", i.e., the graph has a node whose IRI can be turned > >into a URL that points at a source for the constraint. This > >connection could also be indirect. > > > >4/ The constraint validation mechanism could take multiple > >arguments, one of which is an RDF graph and another of which > >contains constraints. In this mechanism, as opposed to the other > >three, there is no way of navigating from the RDF graph to the > >constraint. > > > > > >Some proposals naturally or easily work with several of the above > >mechanisms. > > > > > >peter > > > > > > -- -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 Wednesday, 3 December 2014 22:18:23 UTC