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

The incompatibilities given below appear to come from a misconception on how 
#1 (constraints in the graph itself) and #2 (explicit links from graphs to 
constraint documents) can work.  S4 
(https://www.w3.org/2014/data-shapes/wiki/User_Stories#S4:_Issue_repository) 
contains examples of how OWL constraints and SPIN can handle the story.  SPIN 
can be set up to use either #1 or #2.  OWL constraints can use #2 (but not #1).

Even constraints directly pointed at from individuals (covered by #1 and #2) 
can be used for S4.  All that is needed is some guard on the constraint that 
discriminates between the various issue statuses.

S7 
(https://www.w3.org/2014/data-shapes/wiki/User_Stories#S7:_Different_shapes_at_different_times.2C_or_different_access_at_the_same_time.)
might be different, because there might not be any information in the graph to 
distinguish which constraint(s) should be active.

S8 
(https://www.w3.org/2014/data-shapes/wiki/User_Stories#S8:_Properties_that_can_change_as_they_pass_through_the_workflow.3B_different_shapes_for_different_functions.) 
is either S4 or S7, and thus should be removed.


peter


On 12/03/2014 11:45 PM, Dimitris Kontokostas wrote:
> 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.
>
> Best,
> Dimitris
>
>
> On Thu, Dec 4, 2014 at 12:18 AM, Eric Prud'hommeaux <eric@w3.org
> <mailto:eric@w3.org>> wrote:
>
>     * Holger Knublauch <holger@topquadrant.com
>     <mailto: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 <tel:%2B1.617.599.3509>
>     mobile: +33.6.80.80.35.59 <tel:%2B33.6.80.80.35.59>
>
>     (eric@w3.org <mailto: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

Received on Thursday, 4 December 2014 15:24:01 UTC