[Application-profiles-ig] Shapes and cardinality

Fri Sep 25 18:15:57 BST 2020

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? Phil On 25/09/2020 15:32, Karen Coyle 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/courseinstead ofhttp://schema.org/Course.My>>solution was to put in a rule that boils down to "if your course list>>没有任何课程,你已经取得了一些ort 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>>教育技术的创新。>>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/20200925/a48076a2/attachment.htm>