Re: type and instance and subclass in SHACL documents

So how do you express that form of subclassing? There surely must be a
more precise and formal way than a sentence of prose. Even if it's not
RDFS inferencing, it should be possible to define a different kind of
inferencing for RDF, for example OO-like.

It's not that SHACL implementations will need reasoners, their
implementations just need to deliver results that are consistent with
the official definition.

Hint: RDF rules for definition.

On Thu, May 12, 2016 at 12:03 AM, Holger Knublauch
<holger@topquadrant.com> wrote:
> SHACL doesn't do RDFS inferencing. SHACL uses a trivial and intuitive form
> of subclassing that had been invented long before RDFS, and is
> well-established in OO systems. The fact that RDFS also reinvented a similar
> technique (and added some other inferencing rules) is orthogonal. RDFS does
> not have any rights to block these concepts or the terms for all future
> technologies.
>
> The SHACL spec doesn't use the term inferencing except to state that it
> doesn't rely on inferencing. Even if this WG decides to use other terms than
> "instance", "type" and "subclass", the effect to the end user will be
> exactly the same. It's just a matter of clarity and politics.
>
> Holger
>
>
>
> On 11/05/2016 23:30, Peter F. Patel-Schneider wrote:
>>
>> But SHACL does do RDFS inferencing in the data graph.  In particular, the
>> sh:class depends in RDFS inferencing, namely inference rule rdfs11 from
>> https://www.w3.org/TR/rdf11-mt/#rdfs-entailment.  At one time sh:class
>> also
>> depended on inference rules rdfs4a and rdfs4b as well as the RDFS axiom
>> rdf:first rdfs:domain rdf:List .
>>
>> So saying that SHACL doesn't do RDFS inferencing in the data graph is
>> incorrect.
>>
>>
>> Simmilarly SHACL does RDFS inferencing in the shapes graph when it accepts
>> ex:s1 as a shape in
>>
>> ex:Shape rdfs:subClassOf sh:Shape .
>> ex:s1 rdf:type ex:Shape ;
>>   sh:scopeClass ex:Person ;
>>   sh:constraint [ rdf:type sh:NodeConstraint ;
>>                   sh:nodeKind sh:IRI ] .
>>
>> (This appears to be an acceptable SHACL shape, based on the SHACL
>> specification.)
>>
>>
>> Of course, SHACL does not do *complete* RDFS inferencing.  In particular,
>> there is no SHACL shape in
>>
>> ex:subClassOf rdfs:subPropertyOf rdfs:subClassOf .
>> ex:Shape ex:subClassOf sh:Shape .
>> ex:s1 rdf:type ex:Shape ;
>>   sh:scopeClass ex:Person ;
>>   sh:constraint [ rdf:type sh:NodeConstraint ;
>>                   sh:nodeKind sh:IRI ] .
>>
>>
>> peter
>>
>>
>>
>>
>> On 05/11/2016 01:58 AM, Dimitris Kontokostas wrote:
>>>
>>> I am reopening this old thread which is more related to the other open
>>> discussions we have atm.
>>>
>>> Looking at Tom Baker's emails and in particular [1] (the first three
>>> paragraphs under discussion) I was wondering if this can be a way forward
>>>
>>> in particular say that SHACL uses rdf and rdfs terms but a shacl
>>> processors
>>> takes two immutable graphs (shapes & data) and performs no rdfs
>>> inferencing on
>>> the graphs at all
>>> any inferencing must be performed as a preprocessing step and is out of
>>> scope
>>> for shacl
>>> In there we define the term "shacl instance" which is used in only two
>>> places
>>> in the spec, in sh:classScope and sh:class and no-where else
>>> if people believe that we should disallow optional rdf:type statements
>>> (e.g.
>>> for sh:property) I do not mind if this can unblock the current situation
>>> Peter, would using the terms instance, class or subClassOf be fine under
>>> these
>>> conditions?
>>>
>>> (I am also in favor of dropping sh:entailment btw)
>>>
>>> Any comments on this?
>>>
>>> Best,
>>> Dimitris
>>>
>>> [1]
>>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1605&L=DC-ARCHITECTURE&P=3148
>>>
>>> On Tue, Mar 22, 2016 at 12:56 AM, Holger Knublauch
>>> <holger@topquadrant.com
>>> <mailto:holger@topquadrant.com>> wrote:
>>>
>>>      This is becoming a long long thread about what is an entirely
>>> editorial
>>>      matter. I don't think it deserves the urgency. I also do not agree
>>> that we
>>>      are misusing these terms at all. I believe to make progress we could
>>>
>>>      a) try to find alternative terms (Peter suggested "SHACL instance"
>>> etc,
>>>      but it could also be "is-a")
>>>      b) follow the lead of what other, similar W3C specs are doing
>>>      c) define the terms in the beginning and then use them as <span
>>>      class="term">instance</span> so that the reader knows that we use
>>> that
>>>      definition. That would be my preferred solution.
>>>
>>>      Looking at the OWL 2 spec [1] the term "instance" is used in many
>>>      different contexts, without even being defined:
>>>      - "Each OWL 2 ontology represented as an instance of this conceptual
>>>      structure"
>>>      - "if an individual /a:Peter/ is an instance of the class
>>> /a:Student/,
>>>      and /a:Student/ is a subclass of /a:Person/, then from the OWL 2
>>> semantics
>>>      one can derive that /a:Peter/ is also an instance of /a:Person/."
>>>      - "Instances of the UML classes"
>>>      - Class expressions represent sets of individuals by formally
>>> specifying
>>>      conditions on the individuals' properties; individuals satisfying
>>> these
>>>      conditions are said to be /instances/ of the respective class
>>> expressions"
>>>      - ...
>>>
>>>      Not only does OWL use the term "instance" inconsistently but even
>>> changes
>>>      the RDF term by applying additional OWL semantics. RDFS does not
>>> have the
>>>      monopoly on these terms.
>>>
>>>      The problem is not our use of these terms but the misleading section
>>> 1.1
>>>      that needs to be replaced. I liked a previous proposal from
>>> Dimitris,
>>>      along the lines of "SHACL is based on pattern matching like SPARQL.
>>>      Inferencing is not required but there is no harm if inferencing is
>>>      activated (be it OWL or RDFS inferencing)". Then define the terms
>>> similar
>>>      to what we currently have at the end of section 1.1. And that's it.
>>>
>>>      Holger
>>>
>>>
>>>
>>>      https://www.w3.org/TR/owl2-syntax/
>>>
>>>
>>>      On 22/03/2016 4:15, Peter F. Patel-Schneider wrote:
>>>>
>>>>      I don't think that this helps at all.  In fact, all that it does is
>>>> further
>>>>      obfuscate the issue.  The issue is that the wording needs to be
>>>> clear that in
>>>>
>>>>        sh:shape rdf:type my:Shape .
>>>>        my:subClassOf rdfs:subPropertyOf rdfs:subClassOf.
>>>>        my:Shape my:subClassOf sh:Shape .
>>>>
>>>>      my:Shape is not a SHACL shape, but that in
>>>>
>>>>        sh:shape rdf:type my:Shape .
>>>>        my:Shape rdfs:subClassOf sh:Shape .
>>>>
>>>>      it is.
>>>>
>>>>      There are many cases where the SHACL notion of subclass, instance,
>>>> typing,
>>>>      etc., diverges from the common definition of these notions.
>>>>
>>>>      peter
>>>>
>>>>
>>>>      On 03/21/2016 02:05 AM, Dimitris Kontokostas wrote:
>>>>>
>>>>>      Hi Peter, I did some research on other w3c specs regarding the
>>>>> term instance.
>>>>>
>>>>>      if we changed occurrences of instance from e.g.
>>>>>      "shapes are the instances of sh:Shape" to
>>>>>      "sh:Shape is the class of all shapes"
>>>>>      would this be fine from your side?
>>>>>
>>>>>      Some cases like sh:class and sh:classScope would need extra care
>>>>> of course.
>>>>>
>>>>>      On Mon, Mar 14, 2016 at 12:24 AM, Peter F. Patel-Schneider
>>>>>      <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>
>>>>> <mailto:pfpschneider@gmail.com> <mailto:pfpschneider@gmail.com>> wrote:
>>>>>
>>>>>          Even in this situation I think that "instance" in the rest of
>>>>> the document
>>>>>          needs to be qualified.  Some readers of the document will know
>>>>> about RDFS
>>>>>          instance and will need to be continually reminded that the
>>>>> meaning that they
>>>>>          know for "instance" is not being used in this document.
>>>>>
>>>>>          peter
>>>>>
>>>
>>>
>>>
>>> --
>>> Dimitris Kontokostas
>>> Department of Computer Science, University of Leipzig & DBpedia
>>> Association
>>> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
>>> http://aligned-project.eu <http://aligned-project.eu/>
>>> Homepage:http://aksw.org/DimitrisKontokostas
>>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>>>
>
>

Received on Wednesday, 11 May 2016 22:17:12 UTC