W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > August 2014

Re: Inferencing

From: Holger Knublauch <holger@topquadrant.com>
Date: Sat, 09 Aug 2014 10:43:43 +1000
Message-ID: <53E56EBF.2010303@topquadrant.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, public-rdf-shapes@w3.org
Yes I would also be disappointed, but I believe this is already covered 
by the charter section 3 (Scope):

"Hierarchies of shape definitions
Permit any of a set of shapes to stand for a specified shape, e.g. to 
say that either a User shape or an Employee shape can be used in place 
of a Commentor shape."


On 8/9/14, 10:39 AM, Peter F. Patel-Schneider wrote:
> I would be very disappointed if the RDF graph
> foo rdf:type bar .
> bar rdfs:subClassOf bbb .
> satisfied the constraint
> bbb <= atleast 2 prop
> I thus think that inferencing has a lot to do with constraint checking.
> peter
> On 08/08/2014 05:33 PM, Holger Knublauch wrote:
>> On 8/8/14, 10:24 AM, Eric Prud'hommeaux wrote:
>>> > 3. OPTIONAL A specification of how shape verification interacts with
>>> > inference.
>>> I think this one feel off radar. Did you see any support for this?
>> In general, constraint checking should not *require* inferencing. 
>> However, I
>> believe we should make sure that the topic of inferencing does not get
>> prohibited by the charter. If the WG decides there is a chance to 
>> improve the
>> semantic web stack, then it should be allowed to do so. For example I 
>> do like
>> the idea in one of the ShEx papers to use structural information to 
>> produce
>> new output (e.g. XML trees or other RDF triples). Another example is
>> spin:rule, which is in our experience tremendously useful for defining
>> mappings between ontologies, and to calculate the ex:area of a 
>> ex:Rectangle
>> from ex:width and ex:height. Once we have a mechanism to attach 
>> SPARQL and
>> templates to classes for constraint checking, we could use exactly 
>> the same
>> mechanism to define such production rules - it becomes a rather trivial
>> addition that would keep the solution consistent. All this could go 
>> into a
>> separate, non-normative deliverable, but we should not exclude it.
>> Holger
Received on Saturday, 9 August 2014 00:44:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:40 UTC