[Application-profiles-ig] Shapes and cardinality

Wed Sep 30 10:14:19 BST 2020

On 29/09/2020 16:41, Karen Coyle wrote: >>>On 9/29/20 5:28 AM, Phil Barker wrote:>>Thanks Tom, thanks Karen,>>>>凯伦:你写>>>>>The other option is to use class membership of the shapes.>>could you explain more?>>As Tom addresses below, it is that each shape type would have its own>独特的类成员. So if you have:>>:x rdf:type ex:Book>:y rdf:type ex:Member>>This could be tested,Yes, I know how to test it, but my question how do I represent in the CSV that this needs to be tested? Example 5 just shows that entities which are validated against the Book shape must be instances of sdo:Book. I don't see where is says that there must be any such entity. >>Note that in the table [3] you provided and instance data [4]>成员/业主给出一类sdo:人,布鲁里溃疡t that does not>distinguish the Member shape from the Author shape, so the question to>you is how were you thinking to test for the shapes in this example?>And I guess also how would a shape row with cardinality provide this?Well, honestly, I wasn't thinking much about this aspect when I made that example (it was early days), but I modelled Members with foaf:Person to capture the social relationships of being a club member, so that's would be how I would distinguish Authors from Members. Phil >>I'm fairly confident that the table as it is can express relatively>basic RDF, and more advanced requirements would be out of scope.>>kc>[1]https://www.w3.org/TR/shacl/#targetClass>[2]>https://github.com/dcmi/dcap/blob/master/prototypes/bookclub/bookclubEgs.csv>[3]https://github.com/dcmi/dcap/blob/master/prototypes/bookclub/ap.csv>[4]https://github.com/dcmi/dcap/blob/master/prototypes/bookclub/data.ttl>>>>>Tom, yes, getting a validation error if the graph does not have at>>least one 'rdf:type ex:Book' is what I am after. I'm not so>>interested in the mechanism for how to raise that error (I can do>>that) as in how to put the information for what I want checked into>>the application profile.>>>>At the moment I am thinking that I could probably go back to the>>pattern that I used in the first example I produced for this group[1>><https://docs.google.com/spreadsheets/d/1sj_3bLBy1vtMimlJuiw54BsgmUMcTb9Xq8E9zyUz7zo/edit#gid=71724746>],>>where I had one sheet for terms that are properties (conforming to>>what we've done here) and others for terms that are classes and for>>the profile as a whole.>>>>Phil>>>>1.>>https://docs.google.com/spreadsheets/d/1sj_3bLBy1vtMimlJuiw54BsgmUMcTb9Xq8E9zyUz7zo/edit#gid=71724746>>>>On 29/09/2020 12:56, Thomas Baker wrote:>>>>>On 9/24/20 7:47 AM, Phil Barker wrote:>>>>>>My use case for this comes from validation where I have found errors>>>>>>in instance data cause by people mistyping class ids, e.g.>>>>>>http://schema.org/courseinsteadofhttp://schema.org/Course.My>>>>>>solution was to put in a rule that boils down to "if your course>>>>>>list doesn't have any Courses in it, you've made some sort of>>>>>>mistake".>>>I take Karen's point (and agree) that your use case can>>>be met by a profile with a "course list shape" which>>>defines a relationship (eg, 'hasCourse'?) between the>>>subject entity (the course list) to an object entity that>>>is described with a mandatory rdf:type arc for>>>http://schema.org/Course(as per a "course shape"). In>>>ShEx:>>>>>>foo:CourseListShape {>>>bar:hasCourse @foo:CourseShape>>>}>>>>>>foo:CourseShape {>>>rdf:type sdo:Course>>>}>>>>>>Similarly, as Karen points out, a "bookclub shape" can>>>require relationships to books and members (as described>>>in book shapes and member shapes, respectively).>>>>>>foo:BookClubShape {>>>bar:hasBook @foo:BookShape>>>bar:hasMember @foo:MemberShape>>>}>>>>>>However, if I correctly understand, you want to treat an>>>entire graph (the "instance data") as a "course list",>>>eg:>>>>>>:x rdf:type sdo:Course>>>:y rdf:type sdo:Course>>>:z rdf:type sdo:Course>>>>>>and you want to get a validation error if the graph does>>>not have at least one 'rdf:type sdo:Course' triple. And>>>you want to get this result without having to create an>>>entity (':e') for "course list":>>>>>>:e ex:hasCourse :x - NOT!>>>:e ex:hasCourse :y - NOT!>>>:e ex:hasCourse :z - NOT!>>>>>>Similarly, you would like to treat the following graph as>>>a "bookclub":>>>>>>:x rdf:type ex:Book>>>:y rdf:type ex:Member>>>>>>and get a validation error if the graph does not have at>>>least one 'rdf:type ex:Book' arc and one 'rdf:type>>>ex:Member' arc, and without having to create an entity>>>(':e') for "bookclub":>>>>>>:e bar:hasBook :x - NOT!>>>:e bar:hasMember :y - NOT!>>>>>>Have I correctly understood your requirement?>>>>>>EricP points out that testing the cardinality of triples>>>over an entire graph to raise validation errors is>>>currently beyond the scope of ShEx (or SHACL).>>>>>>In principle, it could be supported in ShEx by extending>>>shape maps with cardinality. A shape map defines a set of>>>nodes in a graph, either by query or by simple>>>numeration, and specifies the shapes against which those>>>nodes are to be validated.>>>>>>For example, the following hypothetical shape map -->>>hypothetical because cardinality ('+' for 'one or more')>>>is not supported for ShEx shape maps -- could be wrapped>>>in a context where an error would be raised if a graph>>>did not have at least one 'rdf:type ex:Book' arc and one>>>'rdf:type ex:Member' arc:>>>>>>{>>>{FOCUS rdf:type ex:Book}@<#BookShape>,>>>{FOCUS rdf:type ex:Member}@<#MemberShape>>>>}+>>>>>>More simply, perhaps, one could check for the presence>>>(or not) of a given triple in the graph with a SPARQL>>>query.>>>>>>The DCAP CSV format we are designing does not have its>>>own validation semantics -- nor should it, because we do>>>not have the resources to invent yet another validation>>>language alongside ShEx, SHACL, JSON Schema, and the>>>like. As I see it, the value of the DCAP CSV format,>>>beyond that of presenting a profile as a readable table,>>>depends on how well it can be translated into actionable>>>schemas.>>>>>>On 2020-09-25 07:15, Phil Barker wrote:>>>>So you're essentially suggesting using this spec would mea that I>>>>have to>>>>model my data in a certain way, e.g. have a top-level entity of>>>>BookClub or>>>>CourseList whether I want one or not?>>>As I see it, your use cases could indeed be met by>>>modeling your data with entities for BookClub and>>>CourseList, described in conformance with BookClub and>>>CourseList shapes, as Karen has suggested.>>>>>>However, if existing validation languages cannot meet>>>your requirement, then the DCAP CSV format, which depends>>>on such languages to be usable as the basis of>>>validation, cannot be expected to meet the requirement.>>>It is also not clear to me how one would convey such a>>>validation condition within the limitations of a tabular>>>format.>>>>>>I would therefore see the requirement as out of scope for>>>the DCAP CSV format -- as something that would need to be>>>handled outside of the profile itself, for example with>>>SPARQL queries.>>>>>>Tom>>>>>-->>>>Phil Barker <http://people.pjjk.net/phil>.http://people.pjjk.net/phil>>CETIS LLP <https://www.cetis.org.uk>: a cooperative consultancy for>>innovation in education technology.>>PJJK Limited <https://www.pjjk.co.uk>: technology to enhance>>learning; information systems for education.>>>>CETIS is a co-operative limited liability partnership, registered in>>England number OC399090>>PJJK Limited is registered in Scotland as a private limited company,>>number SC569282.>>>-- Phil Barker <http://people.pjjk.net/phil>.http://people.pjjk.net/philCETIS LLP <https://www.cetis.org.uk>: a cooperative consultancy for innovation in education technology. PJJK Limited <https://www.pjjk.co.uk>: technology to enhance learning; information systems for education. CETIS is a co-operative limited liability partnership, registered in England number OC399090 PJJK Limited is registered in Scotland as a private limited company, number SC569282. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.www.voudr.com/pipermail/application-profiles-ig/attachments/20200930/a8bb46c9/attachment-0001.htm>