W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2016

Re: type and instance and subclass in SHACL documents

From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Date: Sat, 12 Mar 2016 13:02:33 +0200
Message-ID: <CA+u4+a1RjH6BAPTu9v2vp65a5J-a3uR+3jXnkOvEJCs0i2rA6g@mail.gmail.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Cc: Karen Coyle <kcoyle@kcoyle.net>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
Peter, you are one of the very few (if not the only) person in the WG who
can understand these differences and help us overcome them.
according to your opinion,
- what parts of RDF/RDFS can be included in SHACL without altering any
resolutions we had in this regard?
- how does the spec needs to change to accommodate the different in meaning
terms of type and instance?

I will try to make an attempt but as I said you have the expertise to help
us resolve this problems
would something in the lines of the following work for section 1.1?
shacl uses rdf and rdfs terms but performs no rdfs reasoning at all even
for core rdfs terms i.e. a triple like rdfs:range ex:label "range" . does
not infer  ex:label rdf:type rdf:Property when this triple is validated in
SHACL. When explicitly stated, SHACL may compute the transitive closure of
some rdfs properties like rdfs:subClassOf through sparql property paths but
without performing complete rdfs inferencing

On Sat, Mar 12, 2016 at 5:36 AM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> Using the RDFS definition of instance, rdfs:label is an instance of
> rdf:Property so it is in the scope of the shape and there is a violation.
> Using the SHACL definition of instance, rdfs:label is *not* an instance of
> rdf:Property so it is *not* in scope and there is *no* violation.
>
> peter
>
>
> On 03/11/2016 04:50 PM, Karen Coyle wrote:
> > Peter, I admit that I, too, am having trouble understanding this. (And
> so it
> > isn't all on Peter, if anyone else "gets it" maybe they could weight
> in.) The
> > SHACL document uses the term "instance" 78 times. I admit I only looked
> at the
> > first couple of dozen of those uses. For the most part they appear to me
> to
> > conform to the RDFS definition of "instance" - meaning an instance of
> class.
> > In some cases the term is used more colloquially, but those places in the
> > document don't seem to be definitional.
> >
> > You say that it doesn't validate, but can you say what the difference is
> in
> > the two definitions? I still see it as having to do with the vocabulary
> > definition as opposed to the SHACL validation, but you didn't buy that
> when I
> > suggested it. If I were to use a typical OWL-based validation, rdfs:range
> > ex:label "range" would be flagged as inconsistent. The same would be
> true if I
> > would have
> >   ex:someSubject dct:type "text" .
> > (dct:type has a range of rdf-schema#Class)
> >
> > If this isn't the issue, I would sure like to know what is.
> >
> > Thanks,
> > kc
> >
> > On 3/11/16 2:22 PM, Peter F. Patel-Schneider wrote:
> >> The definition of SHACL depends on "instance".  This can be read to mean
> >> "RDFS instance" or "SHACL instance".  Under the former meaning the data
> graph
> >> does not validate against the shape.   Under the latter meaning the
> data graph
> >> does validate against the shape.
> >>
> >> peter
> >>
> >>
> >> On 03/11/2016 02:15 PM, Irene Polikoff wrote:
> >>> I don¹t understand what you mean by
> >>>
> >>> "validates against this shape under SHACL instance but not under RDFS
> >>> instance.²
> >>>
> >>> I am not able to parse the sentence.
> >>>
> >>> What are you doing? Taking a shape described and the graph described
> and
> >>> running it against SHACL engine? What execution validates and what
> >>> execution doesn¹t validate?
> >>>
> >>>
> >>>
> >>> Irene
> >>>
> >>>
> >>>
> >>> On 3/11/16, 5:03 PM, "Peter F. Patel-Schneider" <
> pfpschneider@gmail.com>
> >>> wrote:
> >>>
> >>>> On 03/11/2016 01:01 PM, Karen Coyle wrote:
> >>>>>
> >>>>>
> >>>>> On 3/11/16 11:43 AM, Peter F. Patel-Schneider wrote:
> >>>>>> Consider the following shape (using obvious prefix declarations)
> >>>>>>
> >>>>>> sh:propertyShape a sh:Shape ;
> >>>>>>    sh:scopeClass rdf:Property ;
> >>>>>>    sh:property [ sh:predicate rdfs:label ;
> >>>>>>                  sh:minCount 1 ] .
> >>>>>>
> >>>>>> The data graph (using obvious prefix declarations)
> >>>>>>
> >>>>>> rdfs:range ex:label "range" .
> >>>>>>
> >>>>>> validates against this shape under SHACL instance but not under RDFS
> >>>>>> instance.
> >>>>>
> >>>>> Isn't this a problem with every vocabulary and not just RDFS? If the
> >>>>> rules of
> >>>>> the vocabulary (such as domain and range) are not encoded as such in
> >>>>> SHACL
> >>>>> then the SHACL result can be "in violation" of the vocabulary
> >>>>> definition.
> >>>>>
> >>>>> Now, if that is the case then I understand that violating the
> foundation
> >>>>> vocabulary of RDF/RDFS may be more grave than violating a
> user-developed
> >>>>> vocabulary, and in some cases doing the latter may indeed be the
> >>>>> intention of
> >>>>> the SHACL definition. So do we want to build into SHACL that it must
> >>>>> follow
> >>>>> RDF/RDFS property and class definitions? And how feasible is that?
> >>>>>
> >>>>> kc
> >>>>>
> >>>>
> >>>> This is only a real problem because SHACL uses "instance" in its
> >>>> specification, this term is also used centrally in RDFS, and SHACL
> uses
> >>>> RDFS
> >>>> vocabulary.
> >>>>
> >>>> The question then is how to read "instance" in SHACL documentation,
> i.e.,
> >>>> how
> >>>> to prevent readers of the SHACL documentation from seeing "RDFS
> instance"
> >>>> where "SHACL instance" is meant.
> >>>>
> >>>>
> >>>> peter
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://
http://aligned-project.eu
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Saturday, 12 March 2016 11:03:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:30 UTC