- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 01 Aug 2014 09:16:05 +1000
- To: public-rdf-shapes@w3.org
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