W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > July 2014

Re: AW: Thoughts on validation requirements

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Wed, 30 Jul 2014 08:52:29 -0700
Message-ID: <53D914BD.4020608@gmail.com>
To: Eric Prud'hommeaux <eric@w3.org>
CC: public-rdf-shapes@w3.org, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, "Bosch, Thomas" <Thomas.Bosch@gesis.org>

On 07/30/2014 07:57 AM, Eric Prud'hommeaux wrote:
> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-07-29 08:01-0700]
>> On 07/29/2014 03:43 AM, Eric Prud'hommeaux wrote:
>>> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-07-28 07:54-0700]
>>>> On 07/28/2014 02:20 AM, Eric Prud'hommeaux wrote:
>>>>> On Jul 28, 2014 12:08 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
>>>>> wrote:
>> [...]
>>>> An RDF document, on the other hand, almost invariably contains
>>>> multiple somethings, very often not arranged in a tree, and
>>>> sometimes even without any connection between them.  In RDF it is
>>>> generally permissable to have any sort of information, whereas XML
>>>> information is generally required to fit into what is expected.
>>> I agree, but fear this is a sort of selection bias.
>> Well obviously there is a bias towards using RDF for multiple
>> somethings, because RDF is good at that and other formats are not.
>> Because of this virtuous bias, there is the concomitant bias that
>> there is relatively less RDF that is used for single somethings.
>> There is, of course, nothing wrong with this so far.
>> It may be that because RDF is good for multiple somethings, some
>> people think that it is not good for single somethings.  If so, this
>> would be somewhat unfortunate.
> Agreed, and that's probably a point that will require constant
> reminders, though the cases I'm referring to use multiple somethings,
> see "Linked Data Basic Profile 1.0 - Use Cases and Requirements".
> <http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/#usecases>
> Below, Consider a HospitalTransferRecord from Clinic A to Clinic B.
> This would incorporate a bunch of somethings like a target problem,
> vitals, prescriptions, and a patient (well, more rigorously just a
> person temporarily acting in the role of patient).
>> However, this certainly doesn't mean that RDF validation should
>> ignore the common situation of multiple somethings, most or all with
>> explicit types.  Nor does it mean that RDF validation should be
>> targeted towards single untyped somethings.  To do either of these
>> is to ignore RDF's strengths.
> I see the multiple somethings as a strong case for detaching the shape
> (the way that a particular app is using these types) from the types
> themselves.

This is where we part company.  I see this as a strong case for keeping the 
constraints tied to types.  Ignoring type information here is just throwing 
away useful information, making it harder to validate documents.

> Even if Clinic A and Clinic B are in the same clincal
> network, they'll capture different information about e.g. the
> admitting physician's credentials. In OWL, one would probably capture
> these as anonymous restrictions, e.g. ClinicB:AdminissionRecord:
>    Class: ClinicB:AdmissionRecord
>      SubClassOf:
>        clin:AdmissionRecord,
>        clin:admitter only
>          ((clin:credential some (clin:authority only ({"AMA" , "GMC"})))
>           and (clin:credential min 1 owl:Thing))

I'm not sure just what you are trying to get at, but it seems exceedingly 
strange to me not to use type information here, as in something like

AdmissionRecord & E originalAdmission
<= ...

as a constraint on the information associated with an original admission and

<= ...

as a constraint on all admission records.

>> So I remain very skeptical that ShEx is a viable start towards RDF
>> validation, as it appears to me to be targeted towards an uncommon
>> use of RDF and not easily extended to nicely cover the bulk of
>> extant and proposed RDF.
>>> Perhaps the
>>> majority of LDP uses include a backend which is not a triple store
>>> (possibly SQL, possibly state stored in the position of a lightswitch
>>> on a wall). In these cases, the data one posts must be limited to the
>>> exact arrangement of somethings that the server expects or data will
>>> be (silently) dropped. I suspect that the majority of the business use
>>> cases on the horizon for RDF involve services that are not willing to
>>> store arbitrary triples.
>> Even if true this is at best an argument for validation that covers
>> all (local) triples.  It still doesn't get one from multiple
>> somethings to single somethings.  I'm also still skeptical that
>> covering all (local) triples is a good idea even here, as it would
>> prohibit, for example, extra information coming from a node
>> belonging to an unexpected (or maybe even expected) subtype.
>>>> Validation then should work differently in RDF than in XML.  My view
>>>> of RDF validation is determining whether the instances of a type
>>>> (not necessarily explicitly signalled by an rdf:type link) meet some
>>>> constraint, and that RDF validation generally involves multiple
>>>> types, often unrelated types.  I don't see how ShEx can do this, and
>>>> thus my questions as to how ShEx can do RDF validation.
>>> What if shapes were types? I think that would meet your definition.
>> Well, that's the method used in Stardog ICV, and in lots of work on
>> constraints over logical formalisms (including description logics).
> I don't see ShEx has having a problem with multiple somethings. The
> ShExC for the above ClinicB:AdmissionRecord could set licensing
> requirements on the admitting physician and coding requirements on the
> principle complaint:
>    ClinicB:AdmissionRecord {
>      clin:admitter {
>        clin:credential { clin:authority ("AMA" | "GMC") }+
>      }
>      clin:principleComplaint {
>        hl7:coding { hl7:CD.CodingSystem ("SNOMED" | "LOINC") }
>      }+
>    }

How does ShEx turn this kind of thing into constraints on admission records? 
All I see here is something that can recognize nice-looking admission records, 
not something that required that admission records look nice, and I don't see 
anything in the ShEx machinery that can make this constraint-checking happen.

>> However, just making shapes be types doesn't immediately get one
>> from ShEx to something that can nicely handle multiple somethings in
>> RDF.  One also needs machinery to require that each instance of a
>> particular type must match a particular constraint type.
> Why do we neet to attach it to a type? Wouldn't that mean that every
> reusable object would have to have a bunch of types attempting to
> predict all of the ways that data might be used? For instance, would
> the admitting physician need to have type arcs asserting that he/she
> was a bethIsreal:SurgicalPhysician, bethIsreal:EDAdmittingPhysician,
> BOSchildrens:Surgeon, mgh:ThoracicSurgeon, mgh:AdmittingPhysician?

Why would this be needed?  Physicians should have type links stating that they 
are physicians.  Other information would be used to set up the other 
requirements.  Constraints can be written against the types and against the 
other information - whatever is needed.  Note that I'm not saying that the 
only information that can trigger constraint checking is type information, 
just that it seems exceedingly strange to not use type information where it is 
relevant, and that type information is the most relevant information of all to 
trigger constraints.

> I'd expect that the physician's record should only advertise the
> type arcs that are part of some shared ontology:
>    <Pat> a foaf:Person , clin:Physician .
> If the type arcs are only notionally attached to the data for the
> purposes of verification, then the argument that they need to be types
> is circular; they're only there because some verification system thinks
> in terms of types.

The type information is there because that's one of the main kinds of 
information in RDF.  Given this, it should not be surprising that much of the 
constraint checking triggers off the types.

>>> There's some language (ShEx, Resource Shapes, Description Set Profiles
>>> or something else whose name I can't recall) to verify that a node in
>>> an instance graph matches a declared structure in a schema. Some
>>> mechanism like oslc:resourceShape associates a graph node with that
>>> structure. Does that fit your view?
>> Maybe.  I'm not sure how Resource Shapes 2.0 works, as the
>> description is very loose.  It does appear that typed shapes are
>> what is intended to be used for what I think of as the usual case of
>> RDF validation - requiring that instances of a class have a
>> particular shape.  However, some aspects of Resource Shapes 2.0
>> appear to be inimical to type hierarchies.
> It seems like predicates like oslc:resourceShape give us the duck
> typing that we need to get practical interoperability out of our
> reusable somethings.

Well, oslc:resourceShape appears to be a way of starting constraint checking 
at a particular point, but then the optionality stuff seems to get in the way. 
  I would find it very useful to have an example where multiple shapes apply 
to resources, showing how the optionality stuff is used in practice.

Received on Wednesday, 30 July 2014 15:53:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:39 UTC