Re: Inferencing

I don't see the interaction here.  Hierarchies of shape definitions appear to 
allow more things to match when doing constraint-based recognition.  Here 
instead there is the dual notion of more things being required to match.

peter


On 08/08/2014 05:43 PM, Holger Knublauch wrote:
> 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."
>
> Holger
>
>
> 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 01:16:09 UTC