Re: another pass at shapes distinct from classes docs

* Holger Knublauch <holger@topquadrant.com> [2015-02-07 10:13+1000]
> 
> On 2/7/15 12:34 AM, Eric Prud'hommeaux wrote:
> >* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2015-02-06 06:11-0800]
> >>The document is getting a bit better, but it is still very rough.
> >>
> >>A big problem is the example.  In situations where objects have types it is
> >>natural to use these types to control the constraints, and even to drive the
> >>entire modelling process.  In the example, what makes an object an issue?
> >>Is it an rdf:type link to ex:Issue, or is it two property-value pairs of the
> >>right form?  I think that if you want to introduce shapes unrelated to
> >>classes then you cannot have classes that mirror the shapes.  Like it or
> >>not, rdf:type is more equal than other properties.
> >I don't see this linkage in primers for XML Schema, JSON Schema, Relax
> >NG, Schematron,
> 
> XML documents often have pointers to a DTD or schema. One of the
> strengths of RDF-based systems is that you can build applications
> that dynamically adjust their behavior depending on the data that
> they get (dynamic input forms, rules etc). For that reason, it is a
> good practice to have data that is self-describing.

Yes, XML documents point back to schemas or DTD so that folks have
some documentation of semantics. That's one of the things that makes
XML quite difficult to reuse and combine; there's frequently a 1:1
linkage between semantics and structure. RDF is not so restricted.

My point remains that primers talking about schemas, e.g. XML, JSON,
SQL, ASN-1, YAMLm etc, don't get into that. They just explain why this
document matches this schema. (Sun External Data Representation may be
an exception, but that's because its use was restricted to defining
SUN RPC interfaces.)


> >but oh well, I've added an explicit statement:
> >[[
> >The mechanism by which the instance data is associated with, or
> >validated against the a shape is not described as this point.
> >
> ><span class="todo">This WG is expected to define ways to link instance
> >data to shapes, e.g. instance-shape, class-to-shape,
> >query-endpoint-to-shape, etc.  This document may include examples of
> >such linkages.</span>
> 
> Just having a vague notion of linkage with "examples" will not be
> acceptable to us. The spec needs to clearly define the minimum
> rules, and we need to deliver test cases. If we continue with the
> currently established practice, then following the rdf:type triple
> is an obvious starting point. Other platforms such as OSLC may
> define additional entry points, and may also ignore the rdf:type
> triple for certain tasks. But if we stay too vague, we throw out the
> baby with the bathwater, and (unnecessarily) sacrifice
> interoperability.

"This instance passes/fails this shape" is quite clear. Adding a type
arc is effectively a non-starter for this group; there are too many
people who see that is hampering re-usability of the data. Asserting
any linkage is complicated editorially as we'd have to explain e.g.

[[
This example describes data being entered into an Issue tracking
database. Some interface <http://issue.example/insert-iface-1>
describes its requirement for POSTed SPARQL INSERTs as:

  <http://issue.example/insert-iface-1>
    sparql2:sparql-UPDATE-shape¹ sh:IssueShape .

This example doesn't imply that other mechanisms can't be used to
associate data with shapes, for instance an LDP Container might assert:

  <http://issue.example/LDP/Issues2> a ldp:Container
    oslc:resourceShape¹ sh:IssueShape .

which would say that every issue posted to the ldp:Container must
conform to sh:IssueShape.

¹The predicates sparql2:sparql-UPDATE-shape and oslc:resourceShape are
not specified in LDOM. sparql2:sparql-UPDATE-shape is made up for this
explaination.
]]

This could certainly go into the document, but there's no reason to
rub everyone's face in it at the top.


> Holger
> 
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Saturday, 7 February 2015 09:58:24 UTC