Re: link from ns/shacl to ns/shacl-shacl

Hi, this issue was originally raised by me and we had a few alternatives
available, including something like sh:suggestedShapesGraph iirc.
In the end we decided to keep sh:shapesGraph to reduce the terms we produce.

I am not sure if I can make it to the call today but.
I think having a link from a vocabulary to the "suggested" shapes graph is
a good practice and we should keep and use this feature on shacl.ttl as well
We can revisit our decision to overload the sh:shapesGraph with this
semantics if this brings (or could bring) problems

Best,
Dimitris

On Mon, Apr 10, 2017 at 1:39 PM, Sandro Hawke <sandro@w3.org> wrote:

>
>
> On April 10, 2017 12:22:58 AM EDT, Holger Knublauch <
> holger@topquadrant.com> wrote:
> >I do agree that for many data models there will be one very strong
> >"default" shapes graph. However, there was quite some resistance
> >against
> >that idea within the WG leading to the point where even sh:targetClass
> >statements were frowned upon by some, because they may tie classes too
> >much to shapes.
> >
> >In the case of shacl.ttl the shacl-shacl.ttl is one candidate default
> >shapes graph (albeit only for SHACL Core). But I expect that many
> >shapes
> >graphs/ontologies will owl:import the shacl.ttl file.
> >
> >As soon as any file has a transitive owl:imports relation to that file,
> >
> >it would mean that any locally defined sh:shapesGraph triples would be
> >augmented by that automatic sh:shapesGraph triple. We should be
> >prepared
> >for a future in which some people will mix shape, class and data
> >definitions all in the same owl:imports closure. So assuming someone
> >has
> >a data graph "mypersons" which owl:imports "personontology" and this
> >has
> >a sh:shapesGraph link, then these shapes would apply to all data graphs
> >
> >that use that ontology. Even worse, there might be a lot of unnecessary
> >
> >churn with the same shapes being validated over and over again.
> >
> >While I have no experience with using sh:shapesGraph "in the wild" yet,
> >
> >I think I would prefer to reserve sh:shapesGraph for the cases in which
> >
> >a data graph ("instances") points at a shapes graph. The SHACL.ttl file
> >
> >contains classes, so it does not really fall into that category. So
> >yes,
> >I believe there may be cases that need further discussion and it might
> >be more prudent to select another property for this particular case.
> >
> >How urgent is this decision? I would suggest we put it on the agenda
> >for
> >Wednesday.
> >
>
> It's not urgent.   This link doesn't have to be normative in SHACL.
>
> I agree with your argument.   Maybe the link is suggestedShapesGraph, and
> it's legit to have have multiple ones as alternatives, instead of all
> applying.
>
>    - Sandro
>
> >Holger
> >
> >
> >On 10/04/2017 13:44, Sandro Hawke wrote:
> >> Tim was explicit that rdfs:seeAlso wouldn't be good enough, since he
> >> wants machines to able to do the importing.
> >>
> >> He may not have thought through all the implications, though. What
> >> kinds of unpredictable things might happen, do you think?  I suppose
> >> it make make some systems validate all their shapes, when that isn't
> >> needed.
> >>
> >>       -- Sandro
> >>
> >>
> >> On 04/09/2017 10:56 PM, Holger Knublauch wrote:
> >>> I think sh:shapesGraph would be an option here:
> >>>
> >>>     https://www.w3.org/TR/shacl/#sh-shapes-graph
> >>>
> >>> However, given that the shacl namespace may be imported into a wide
> >>> variety of use cases and thus the potential wide implications of
> >>> adding such a triple are unpredictable right now, what about just
> >>> rdfs:seeAlso?
> >>>
> >>> Holger
> >>>
> >>>
> >>> On 10/04/2017 12:21, Sandro Hawke wrote:
> >>>> TimBL asked us to put a machine readable link from the SHACL
> >>>> namespace document (https://www.w3.org/ns/shacl) to the SHACL
> >>>> document which can be used to validate documents written using that
> >
> >>>> namespace (https://www.w3.org/ns/shacl-shacl).   This seems like
> >the
> >>>> kind of link that would be generally useful, even if only as a
> >rough
> >>>> default.  Obviously in many cases, one namespace would be
> >>>> appropriately used in lots of different shapes.  But in some cases
> >>>> (eg SHACL) where there's a sensible default, it'd be nice for the
> >>>> machines to be able to find it.   So, has anyone made such a
> >>>> predicate?    If not, is there a reason not to make it up now, as a
> >
> >>>> non-rec-track extension?
> >>>>
> >>>>      -- Sandro
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT