Re: rdfdatashapestracker-ISSUE-3 (Shape association): How is a shape associated with a graph?

* Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> [2014-12-04 09:45+0200]
> Looks like we have five options available, four mentioned by Peter and one
> by Eric (assigning a shape to an instance).
> Are there any other options? I cannot think of any.
> 
> I believe that we are not limited to a single option and we can define more
> than one shape identification entry points.
> Thus, I think that it would be easier if we started to exclude some of the
> options based on the use cases.
> 
> For instance, I think that #1 and #5 are not easily compatible with S4, S7
> & S8.

It seems the meta-lesson here is that we need a validation system that
is reusable for different use cases. By analogy, XML Schema provides a
definition language which was later used by WSDL to associate input,
output and exception messages with interfaces. We don't need to define
all of the constructs to invoke validation, just the language to define
a valid dataset.


> Best,
> Dimitris
> 
> 
> On Thu, Dec 4, 2014 at 12:18 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> > * 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.
> >
> >
> 
> 
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig
> Research Group: http://aksw.org
> Homepage:http://aksw.org/DimitrisKontokostas

-- 
-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 Thursday, 4 December 2014 10:34:06 UTC