Re: AW: Thoughts on validation requirements

On 8/1/14, 5:26 AM, Arthur Ryman wrote:
> Holger,
>
>   An RDF document is a set of triples (statements). The triples do not
> necessarily have to look like they came from an object (in the OO sense),
> i.e. that there is one distinguished root node (this, self) that has some
> type (class) attribute, and other triples (properties) that have the root
> node as their subject, and so on recursively.
>
> If you think of an RDF document as a graph, then there should be no special
> significance to a node that happens to have a type attribute. We should be
> able to state constraints on the graph in the absence of type triples.
> This is very consistent with SPARQL. SPARQL includes a graph pattern
> matching language. SPARQL queries are not associated with any specific
> type, so why should constraints be?
SPIN has the concept of global constraints, so the object-oriented 
design is really just a convenient design recommendation. But in our 
experience, having an rdf:type is the norm, and typeless resources are 
the exception. I don't think it is a good idea to base the design of 
such an important aspect of this WG on the exception cases. Attaching 
the semantics to classes gives you a natural way of encapsulation, 
inheritance and allows us to reuse all existing ontologies in an 
incremental way, rather than coming up with a parallel world of 
free-floating shapes.

It would be good to look at the use cases identified in the requirements 
documents to see how often an rdf:type triple has negative consequences. 
When I ported OSLC Shapes to SPIN I tried it with the example in the 
OSLC spec and found no problems with attaching constraints to classes. 
Neither have we at TopQuadrant ever encountered a case that was not 
"object-oriented". I would like to see counter-examples because it's 
easy to get lost in theory here. Yes: RDF is all about graphs, but does 
this mean that a constraint language may not exploit certain triples 
from those graphs and give them special meaning?

Another analogy is XML, where every XML element also has a name. This is 
comparable to its rdf:type.

Having said this, if SPIN were the foundation of this work, I am 
confident that it could be generalized to cover your use case too. If we 
can avoid it though, I would strongly vote for a simpler language that 
covers most use cases. The semantic web stack is already full of 
over-complicated languages that nobody understands. Object-orientation 
is mainstream.
>
> However, even if the RDF document was the representation of some OO-like
> object that had a root node and some type (class) attribute, its shape
> could vary depending on the context. For example, when you create a
> resource using POST, certain triples will be absent, e.g. creation date,
> and if present they may be ignored or the server may fail the request.
> When you GET that resource you will normally see other triples that the
> server added, e.g. creation date, and these will occur exactly once.
Yes absolutely. The context is important, and (as mentioned a few times 
here on various threads), it is perfectly reasonable to have different 
schema/shape definitions returned by each service. The equivalent 
concept in RDF is that of named graphs. So, POST would return one 
schema, and GET would return another. There is no single truth. Why 
should an application "download" the whole semantic web if it just needs 
a single local graph?

>   
> OSLC lets you associate shapes with operations. Resource instances may
> link to shape resources that describe the instance. There is no need to
> base the association between resources and constraints using an RDF type.
> A shape could apply to several types or to no types.
Yes and I wonder whether this flexibility is worth breaking the (simple 
and consistent) "object-oriented" design used by all other ontology 
languages. You basically end up with a structure of Shapes that strongly 
resembles classes yet is not exactly the same. In our experience, using 
rdf:type triples and classes is a more intuitive mechanism, and it 
already exists, is consistent with OWL etc.

Holger

Received on Thursday, 31 July 2014 23:16:38 UTC