same property in shape

[kcoyle]

An early example that we were given was the situation in which a profile specifies that a property can be either a literal or an IRI. This could be done by making the valueNodeType "IRI LITERAL" for either. However, this does not allow one to place different constraints on IRIs and LITERALs in that row. I suggested something like:

shapeID	shapeLabel	propertyID	propertyLabel	mandatory	repeatable	valueNodeType	valueDataType	valueConstraint	valueConstraintType	valueShape
bookShape	Book	dct:subject	Subject	TRUE	TRUE					subjectShape
subjectShape	Subjects	dct:subject	Subject	FALSE	TRUE	literal	xsd:string
subjectShape	Subjects	dct:subject	Subject	FALSE	TRUE	IRI		http://id.loc.gov/	IRIstem

This was immediately noted as problematic as it has the property dct:subject having as its object a shape that itself has dct:subject as a property. I can imagine similar situations with dct:creator -- although in that case we have created examples using foaf:name.

Is the use of properties in this kind of arc chain a problem? If so, 1) what is the problem? and 2) what is a better solution?

[philbarker]

I think that the use of a shape (subjectShape) is the problem. So far all the shapes we have discussed have been what SHACL calls node shapes [1 <https://www.w3.org/TR/shacl/#node-shapes>], i.e. the describe the arcs that you would expect to see around a node in the graph. Subject shape doesn't do that, it describes the node you would expect to see at the end of an an arc in the graph -- in SHACL this would be a property shape [2 <https://www.w3.org/TR/shacl/#property-shapes>].  In the TAP our equivalent to a SHACL property shape is (roughly speaking) a row. I don't think you need a subjectShape to do what you are trying to do, I think this works: shapeID propertyID propertyLabel mandatory repeatable valueNodeType valueDataType valueConstraint valueConstraintType bookShape dct:subject Subject TRUE TRUE literal IRI bookShape dct:subject Subject FALSE TRUE literal xsd:string bookShape dct:subject Subject FALSE TRUE IRI http://id.loc.gov/ IRIstem Read as: 1. whatever is described by a book shape must have the dct:subject property with a value that is a Literal or an IRI 2. whatever is described by a book shape may have a dct:subject property with a value that is a Literal so long as the Literal is formatted as an xsd:string 3. whatever is described by a book shape may have a dct:subject property with a value that is an IRI so long as the IRI stem begins with http://id.loc.gov/ Even though it doesn't introduce any new "rules" for interpreting the TAP beyond what we cover in the primer (i.e. all of a row must be matched; multiple entries in a cell are alternives; rows are independent of each other), I think this is better placed in the cookbook than primer. Phil 1. https://www.w3.org/TR/shacl/#node-shapes 2. https://www.w3.org/TR/shacl/#property-shapes

On 02/08/2022 20:31, Karen Coyle wrote: An early example that we were given was the situation in which a profile specifies that a property can be either a literal or an IRI. This could be done by making the valueNodeType "IRI LITERAL" for either. However, this does not allow one to place different constraints on IRIs and LITERALs in that row. I suggested something like: shapeID shapeLabel propertyID propertyLabel mandatory repeatable valueNodeType valueDataType valueConstraint valueConstraintType valueShape bookShape Book dct:subject Subject TRUE TRUE subjectShape subjectShape Subjects dct:subject Subject FALSE TRUE literal xsd:string subjectShape Subjects dct:subject Subject FALSE TRUE IRI http://id.loc.gov/ IRIstem This was immediately noted as problematic as it has the property |dct:subject| having as its object a shape that itself has |dct:subject| as a property. I can imagine similar situations with |dct:creator| -- although in that case we have created examples using |foaf:name|. Is the use of properties in this kind of arc chain a problem? If so, 1) what is the problem? and 2) what is a better solution? — Reply to this email directly, view it on GitHub <#76>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFAU7YV3TSPJ4UWRW3TLNDVXFZQDANCNFSM55MJSJHA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- 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.

[kcoyle]

@philbarker Thank you. A very interesting solution.

This is a very important point and one that we have not actually discussed:

describe the arcs that you would expect to see around a node in the graph

In our examples we have used shapes that are what I would call "logic shapes" - and this is an example of that. Another one is the use of ((foaf:name) OR (foaf:givenName AND foaf:familyName)). You have shown a different (and perhaps better) way to express this logic, although it may be harder to explain. The questions that I see are:

1. Does TAP define the structure of the metadata? OR
2. Does TAP define the concepts in the metadata?

For the first one, I wonder if we can reasonably expect the profile developers to know the underlying structure. For the second, do we expect that the concepts and the structure will be compatible? Let's discuss this in a meeting.

[kcoyle]

Close, as per discussion of Aug 4, 2022. Minutes