[Application-profiles-ig] Shapes and cardinality

Fri Sep 25 19:31:31 BST 2020

Phil, there are definite limitations to the table format, no doubt about that. And add to that the requirements of RDF, our options may be limited. There are some RDF->ShEx programs out there, I believe, and it would be great to find out if what we have in a table can actually be used to validate some data based on the profile. I believe that Tom is writing a csv->RDF, and now that virtual DCMI is over he may be able to run some experiments. On 9/25/20 10:15 AM, 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?不,不是。我给了,作为一个选择。另外一些的er option is to use class membership of the shapes. That latter is one that I would like to test after a transform to ShEx to see if the validation works. I admit I'm not well versed in how ShEx validates classes, other than I'm pretty sure they must be in the instance data. (I was on the SHACL group so I got a lot of class validation during that.) And to state the obvious - while anyone can write programs to do whatever they want, we want this CSV to work "out of the box" so it has to work the same for everyone. Anyone can add other columns or rows, but if those require local knowledge then the profile loses some or all of its share-ability. kc >>Phil>>25/09/2020十五32,Karen Coyle写道:>>>>>>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/courseinstead ofhttp://schema.org/Course.My>>>solution was to put in a rule that boils down to "if your course list>>>不哈ve any Courses in it, you've made some sort of mistake".>>>>So that is:>>>>courselistShape sdo:hasCourseInstance [courseID] (mandatory, repeatable)>>>>Actually, to make this closer to our table but easier to type:>>>>shapeID = courselistShape>>property = sdo:hasCourseInstance>>valueType = IRI>>mandatory = y>>repeatable = y>>>>>Translating to the bookclub example, it's reasonable to want to>>>insist that a bookclub must have Books and Members. When I first>>>showed this example there seemed to be general agreement that it was>>>a useful thing to be able to do, and to do simply.>>>>I would see this as:>>>>shapeID = bookclubShape>>property = sdo:book>>shapeReference = bookShapeRef>>mandatory = y>>repeatable = y>>shapeID = bookclubShape>>property = sdo:member>>shapeReference = memberShape>>mandatory = y>>repeatable = y>>>>That makes the book and the member both "things" in the book club.>>>>If you want to use class membership as the test (and that means that>>class declarations must also be in the instance data), the class>>membership declaration (rdf:type) has to be in the profile. There is>>nothing inherently "class" in the shapeIDs, and there will be shapeIDs>>that are not members of any class (well, other than owl:Thing or>>whatever is at the top of every RDF node.) We've talked vaguely about>>class declarations using rdf:type but haven't looked at that lately.>>To me, rdf:type is kind of a special case because instead of having a>>type of value it has a specific value. It seems to me that the only>>place for this in our table is in the constraint area.>>>>shapeID = bookShape>>property = rdf:type>>valueType - IRI>>mandatory = y>>constraint = sdo:Book>>constraintType = ?class?>>>>This then makes the data test-able using classes. Since there must be>>a row with rdf:type it seems that having a row for the shapeID alone>>would be redundant.>>>>What makes this tricky for us is that we haven't tackled constraints>>yet, so my guess here about constraint is just a guess, and I don't>>know what we need for constraint type.>>>>kc>>>>>>>>Phil>>>>>>On 24/09/2020 15:09, Karen Coyle wrote:>>>>All,>>>>>>>>I thought more about the issue of stand-alone metadata shapes and>>>>cardinality. If you recall, the question came up regarding entering>>>>the shape on its own row. To decide that we need to know what>>>>information is required for a shape that would mean that we must>>>>define a row for the shape separate from the property statements. In>>>>particular there was the question of whether we need to be able to>>>>define cardinality on a shape row.>>>>>>>>I've convinced myself that the answer is "no". Here's my thinking:>>>>cardinality is not a function of the "thing" that the shape>>>>represents, it is a function of relationships between things. We see>>>>that on UML-type data diagrams - the cardinality is always on the>>>>relationship line. A standalone metadata "thing" is just some>>>>metadata floating in the metadata soup. When it connects to other>>>>metadata, then there MAY be cardinality on that relationship.>>>>>>>>Then there is the question of the "head" of the metadata profile if>>>>it is stand-alone. (It may be that all shapes are referenced>>>>elsewhere in the metadata, so none are stand-alone.) This is the>>>>only one that I could imagine having cardinality requirements - at>>>>least saying that it is mandatory. However, I think that this can be>>>>inferred if that is needed. There should be only one un-referenced>>>>shape in a given profile. Another way to put this is that if there>>>>is more than one shape defined in a profile it is because it has a>>>>relationship to another shape in the same profile. Otherwise, why>>>>put unrelated shapes in a single profile?>>>>>>>>A shape needs an identifier (we have that) a label (we have that)>>>>and perhaps an annotation (we don't have that). Anything else is a>>>>property statement *about* the thing the shape represents - because,>>>>as we know, shape nodes themselves don't have information, the>>>>information is all in the properties. We could advise use of>>>>dct:description as the property to annotate the shape if that is>>>>desired.>>>>>>>>kc>>>-->>>>>>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/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.>-- Karen Coylekcoyle at kcoyle.nethttp://kcoyle.netskype: kcoylenet