[Application-profiles-ig] Shapes and cardinality

Thu Sep 24 15:47:20 BST 2020

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 doesn't have any Courses in it, you've made some sort of mistake". 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. 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.>>还有我的“头”的问题tadata 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/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/20200924/926d87ca/attachment.htm>