RE: shapes and classes: different

The OSLC motivation for introducing shapes was based on two 
considerations:
1) constraints vs inference
2) statements vs data structures

OSLC is about defining REST APIs that use RDF, aka Linked Data. RDF was 
selected for its data integration benefits. However, that did not change a 
basic fact of life that when a server receives a POST or PUT request it 
has to validate the data. We initially thought that RDFS or OWL could be 
used. However, those are for inferencing, not validation. We became aware 
of the OWL ICV technology from C&P, but we needed an open standard. If OWL 
ICV had became a standard then we would have used it. In the absence of an 
open standard for RDF validation, we defined Shapes. So when people say 
there is no difference between shapes and classes, then I partially agree, 
but only if we adopt Closed World and Non-Unique Naming.

The RDF vocabularies we designed initially were inspired by the OO data 
structures that lived in the servers. For example, we defined pairs of 
mutually inverse properties because we thought there was something special 
about a node being the subject versus the object. This complicated our 
SPARQL queries because we had to use both directions of the predicates. 
Also, blank nodes were used incorrectly. These errors were traceable to us 
making very direct translations of the data structures into RDF. We have 
since tried to simplify our vocabularies and use RDF more correctly.

IMHO, RDF is good for data integration because it is about logical 
statements, not data structures. If the output of this WG is optimized for 
the data structure point of view, it may drive the wrong behavior and we 
may lose the unique value of RDF. Why would developers pick RDF instead 
of, say, plain JSON?

-- Arthur Ryman

Received on Thursday, 29 January 2015 20:54:42 UTC