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

Re: Validation and cool URIs

From: Arthur Ryman <ryman@ca.ibm.com>
Date: Wed, 6 Aug 2014 09:00:10 -0400
To: Holger Knublauch <holger@topquadrant.com>
Cc: public-rdf-shapes@w3.org
Message-ID: <OF4CEF33CA.8CD0DE26-ON85257D2C.0044E5C5-85257D2C.0047702A@ca.ibm.com>
Holger,

You wrote: "What I haven't understood yet is how those principles are 
supposed to work in the original two Shapes submissions, where resources 
do not even have to have an rdf:type - how is this going to be 
self-describing data? What is the entry point into the validation?"

Short answers:
- It is self-describing because the Shape is either linked to the service 
description or the instance document.
- The entry point is the entire RDF document (aka graph) just like in 
SPARQL.  There is not necessarily a special node in the graph. You use a 
general graph pattern to either find a subgraph that must exist (an 
assertion), or to find a subgraph that must not exist (a constraint 
violation). 

Long answers:
The Shapes submission is motivated by Linked Data API considerations. Here 
one deals with REST services. For example, when creating new resources, 
one POSTs an RDF document to some URL. We want to describe the API 
contract for the service. The service is described by a Service 
Description resource. The Service Description resource refers to the Shape 
accepted by the POST request. Shape may require that the request contains 
a node with an rdf:type property. However, the Shape may apply to several 
different rdf:types. The Shape is therefore attached to the service, not 
each type. After the resource is POSTed, the service may added new 
triples, so the Shape of the created resource is different than the Shape 
of the POST request. The created resource may contain a link to its Shape. 
A service that lets you query across a set of resources may also link to a 
set of Shapes that define the data available for querying. This metadata 
both tells you what properties are available and may let you define more 
efficient queries.

The above use cases are orthogonal to use cases where an RDF class defines 
constraints that must be universally obeyed, independent of the context, 
i.e. a bicycle must have two wheels.

Regards, 
___________________________________________________________________________
Arthur Ryman, PhD

Chief Data Officer, Rational
Chief Architect, Portfolio & Strategy Management
Distinguished Engineer | Master Inventor | Academy of Technology

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:   Holger Knublauch <holger@topquadrant.com>
To:     public-rdf-shapes@w3.org, 
Date:   08/04/2014 06:18 PM
Subject:        Re: Validation and cool URIs



Hi Bernard,

I very much second your view point. If we want to be based on RDF, then we 
should honor its basic principles. One of those principles is that of 
self-describing data, where applications can look up the definition of a 
resource by resolving URIs. For example, if a resource declares an 
rdf:type, then an application should be able to look up the definition of 
the class, including its semantic declarations and constraints. This 
should be the default assumption: someone creates an ontology and when he 
publishes it on the web then anyone who wants to reuse that ontology 
should honor the same constraints.

Having said this, applications may overload the default behavior. In 
TopBraid we do this by first looking at local files for the same URI, and 
preferring those over the files from the web. This also makes it possible 
to refer to graphs that do not even exist on the web.

What I haven't understood yet is how those principles are supposed to work 
in the original two Shapes submissions, where resources do not even have 
to have an rdf:type - how is this going to be self-describing data? What 
is the entry point into the validation?

Thanks,
Holger



On 8/4/14, 7:19 PM, Bernard Vatant wrote:
Peter

2014-08-01 16:44 GMT+02:00 Patel-Schneider, Peter <
Peter.Patel-Schneider@nuance.com>:
I don't understand.  Is it a good thing that RDF uses URIs or a bad thing?

RDF using URIs is a state of affairs, like birds wearing feathers, and 
apples growing on apple-trees. Wondering if it's good or bad is pointless, 
but you can't ignore it.

RDF in its philosophy and principles is not separable from the Web 
architecture, which should allow anyone to figure what one commits to when 
using a URI. The same URI can be used with different semantics and 
different logics, defined by different documents, of course, which makes 
already difficult to figure if the usage is twisting or not the original 
declared semantics (and agreed, this is an issue with any language, formal 
or not, there is the authority definition and the real usage) . Is the 
main focus of RDF validation seems to be contexts where such documents are 
known only by applications not connected with the Web, hence not 
accessible from the URIs they use, as the one presented today by Holger 
[1]? I have nothing against that, we've been doing it also in Mondeca for 
more than ten years, using URIs under the hood of applications with 
specific operational semantics, but actually I've always felt uneasy about 
it, because that does not seem to be a cool way to use URIs [2]. 

My hope is that this group will clarify this tension between the use of 
URIs on the Web and in closed environments, and not blur the landscape 
even more.

[1] 
http://lists.w3.org/Archives/Public/public-rdf-shapes/2014Aug/0040.html
[2] http://www.w3.org/TR/cooluris/



 
Received on Wednesday, 6 August 2014 13:01:30 UTC

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