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

Wondering about an example of closed world validation

From: Bernard Vatant <bernard.vatant@mondeca.com>
Date: Wed, 30 Jul 2014 19:01:21 +0200
Message-ID: <CAK4ZFVG_3xHEHpUb+m5ZoQ1qqmbOCcSvqj3Q0qTqkrdhW1DuHg@mail.gmail.com>
To: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
Hello all

This is an example to illustrate a question this group should IMHO clarify.

Suppose I have this (closed world) validation rule (in natural language)
R1 "A value of dcterms:creator must be an instance of foaf:Agent"

Now I have this graph

G = { :x   dcterms:creator [foaf:familyName  "Smith"] }

In a closed world logic, G is not valid against R1, because the value of
dcterms:creator is not explicitly declared as a foaf:Agent

But one could argue that since both data and R1 use elements in the FOAF
namespace, they both abide by FOAF semantics, which includes

A1 : foaf:familyName  rdfs:domain foaf:Person
A2 : foaf:Person rdfs:subClassOf  foaf:Agent

Hence [foaf:familyName "Smith"] is indeed a foaf:Agent, and G is valid
modulo FOAF semantics.

This issue is already known in SPARQL, which can be run against the same
data with or w/o e.g., RDFS inference with different results.

The bottom line is that RDF uses URIs. Classes and predicates URIs have
semantics which are not necessarily explicited in the local graph/data, but
that one can (should?) find out using the Web infrastructure and open world
inferences.

Note that A1 and A2 could be, or not, duplicated in the local graph, and
the inference before validation could be limited to the local graph or
extended to the Web, there again with different results.

Thoughts?

-- 

*Bernard Vatant *
Vocabularies & Data Engineering
Tel :  + 33 (0)9 71 48 84 59
Skype : bernard.vatant
http://google.com/+BernardVatant
--------------------------------------------------------
*Mondeca*
35 boulevard de Strasbourg 75010 Paris
www.mondeca.com
Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>
----------------------------------------------------------
Received on Wednesday, 30 July 2014 17:02:09 UTC

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