- 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
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