Some example TAPs and their interpretation

[philbarker]

I'm not sure where to put this, so I thought I might try here since I'm not sure what githb discussions might be useful for.

It might be useful to have some worked examples of TAPs and their interpretation in human and machine readable form (ShEx, SHACL). These could start simple and build in more complexity, which means that we don't jump straight in to all the complexities of real-world examples. They might be useful in explaining the TAP standard e.g. in the cookbook, and as test cases for any conversion tools.

I'll start with a simple TAP for Books:

Namespaces:

prefix	URI	Note
dct	http://purl.org/dc/terms/	DCMI Metadata Terms
foaf	http://xmlns.com/foaf/0.1/	Friend of a Friend
sdo	https://schema.org/	Schema.org
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#	RDF
xsd	http://www.w3.org/2001/XMLSchema#	XSD: use for data types
	http://example.org/terms#	default

TAP

	shapeID	propertyID	propertyLabel	mandatory	repeatable	valueNodeType	valueDataType	valueConstraint	valueConstraintType	valueShape	note
1	#Book	dct:title	Title	TRUE	FALSE	Literal	rdf:langString
2	#Book	dct:creator	Author	FALSE	TRUE	IRI				#Author
3	#Book	sdo:isbn	ISBN-13	FALSE	FALSE	Literal	xsd:string	^\d{13}$	pattern		Just the thirteen digits, no separators
4	#Book	rdf:type	Type	TRUE	TRUE	IRI		sdo:Book
5	#Author	foaf:givenName	Given name	FALSE	TRUE	Literal	Literal	xsd:string
6	#Author	foaf:familyName	Family name	FALSE	TRUE	Literal	Literal	xsd:string
7	#Author	rdf:type	Type	TRUE	FALSE	IRI		foaf:Person

Leaving aside whether this is a "good" application profile, I think it does a reasonable job of covering the basic use of much of the TAP.

Interpretation

Line 1: Book instance data must have one and only one dct:title of type rdf:langString.
Line 2: Book instance data may have zero or more dct:creator described as an RDF instance with a URI, matching the #Author shape
Line 3: Book instance data may have zero or one sdo:isbn with Literal value being an xsd:string composed of 13 digits only
Line 4: Book instance data must have rdf:type of sdo:Book
Line 5: Author instance data may have zero or more foaf:givenName with Literal value type xsd:string
Line 6: Author instance data may have zero or more foaf:familyName with Literal value type xsd:string
Line 7: Author instance data must have rdf:type of foaf:Person

Possibly Lines 4 and 7 could also be interpreted as "Book/Author instance data is that data which has rdf:type sdo:Book / foaf:Person" otherwise how would we know what was Book instance data? In which case it seems a simple non-extended TAP cannot cope with different shapes for different types of Book.

Example Instance Data

A reasonably complete & conforming instance would be:

@prefix dct:  <http://purl.org/dc/terms/>                      # DCMI Metadata Terms
@prefix foaf: <http://xmlns.com/foaf/0.1/>                     # Friend of a Friend
@prefix sdo:  <https://schema.org/>                            # Schema.org
@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#>    # RDF
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#>              # XSD: use for data types
 
<https://www.wikidata.org/entity/Q19870535> a sdo:Book ;
    dct:title "A Book of Mediterranean Food"@en ;
    dct:creator <https://www.wikidata.org/entity/Q4944293> ;
    sdo:isbn "0123456789123"^^xsd:string .

<https://www.wikidata.org/entity/Q4944293> a foaf:Person ;
   foaf:givenName "Elizabeth"^^xsd:string
   foaf:familyName "David"^^xsd:string

Noting that only rdf:type and dct:title (lines 1, 4 and 7) are mandatory, the simplest conforming instance is something like

# omitting @prefix terms for brevity

_:b0 a sdo:Book;
    dct:title "A Book of Mediterranean Food"@en .

_:b1 a foaf:Person .

I think it is unexpected that there must be a a foaf:Person, even though there is no property pointing to it. This is a consequence of using and mandatory rdf:type to say that authors must be foaf:people.

I don't see any way of saying whether a "top level" object (i.e. a node with no incoming arcs) should or should not be a blank node.

Repeating properties in fully open profiles

Repeating the title langstring is forbidden (line 1) so this fragment does not seem to match the intent of the profile:

_:b0  dct:title "A Book of Mediterranean Food"@en , 
                 "Un libro de comida mediterránea"@es .

Assuming an open profile this example would match as only one statement matches line 1.

_:b0  dct:title "A Book of Mediterranean Food"^^xsd:string, 
                "Un libro de comida mediterránea"@es.

But what really is the difference between these two examples? they both have one statement that matches line 1 and one that doesn't. Does this mean that in an open profile all properties are effectively repeatable?

Likewise, (in and open profile) this is not forbidded even though it does not match the intent of the profile:

_:b0  sdo:isbn "123456789"^^xsd:string .

as is

_:b0  sdo:isbn "123456789"^^xsd:string ,
                       "1234567890123"^^xsd:string .

[kcoyle]

In some of the folders under "Examples" I have presented TAPs and separately the output from Tom's program. See [1], even though I'm revising the TAP for that one at the moment, but the idea is to include all files related to an example. These below could go in a folder there as separate files. I think it's ok for the moment to give these files whatever names are clear and convenient (e.g. prefixes.txt or whatever) as long as there is a short readme that says what the files are. Alternatively, this could be a document in gdocs or a hackmd, but I prefer a github location just for the purposes of keeping things together. I could attempt this if you prefer. Next I'll look at your content (thanks, Phil!) and see what comments I have on that. kc [1] https://github.com/dcmi/dctap/tree/main/examples/dcat-ap

…

On 10/21/21 4:15 AM, Phil Barker wrote: I'm not sure where to put this, so I thought I might try here since I'm not sure what githb discussions might be useful for. It might be useful to have some worked examples of TAPs and their interpretation in human and machine readable form (ShEx, SHACL). These could start simple and build in more complexity, which means that we don't jump straight in to all the complexities of real-world examples. They might be useful in explaining the TAP standard e.g. in the cookbook, and as test cases for any conversion tools. I'll start with a simple TAP for Books: Namespaces: prefix URI Note dct http://purl.org/dc/terms/ <http://purl.org/dc/terms/> DCMI Metadata Terms foaf http://xmlns.com/foaf/0.1/ <http://xmlns.com/foaf/0.1/> Friend of a Friend sdo https://schema.org/ <https://schema.org/> Schema.org rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# <http://www.w3.org/1999/02/22-rdf-syntax-ns#> RDF xsd http://www.w3.org/2001/XMLSchema# <http://www.w3.org/2001/XMLSchema#> XSD: use for data types http://example.org/terms# <http://example.org/terms#> default TAP shapeID propertyID propertyLabel mandatory repeatable valueNodeType valueDataType valueConstraint valueConstraintType valueShape note 1 #Book dct:title Title TRUE FALSE Literal rdf:langString 2 #Book dct:creator Author FALSE TRUE IRI #Author 3 #Book sdo:isbn ISBN-13 FALSE FALSE Literal xsd:string ^\d{13}$ pattern Just the thirteen digits, no separators 4 #Book rdf:type Type TRUE TRUE IRI sdo:Book 5 #Author foaf:givenName Given name FALSE TRUE Literal Literal xsd:string 6 #Author foaf:familyName Family name FALSE TRUE Literal Literal xsd:string 7 #Author rdf:type Type TRUE FALSE IRI foaf:Person Leaving aside whether this is a "good" application profile, I think it does a reasonable job of covering the basic use of much of the TAP. Interpretation *Line 1:* Book instance data must have one and only one dct:title of type rdf:langString. *Line 2:* Book instance data may have zero or more dct:creator described as an RDF instance with a URI, matching the #Author shape *Line 3:* Book instance data may have zero or one sdo:isbn with Literal value being an xsd:string composed of 13 digits only *Line 4:* Book instance data must have rdf:type of sdo:Book *Line 5:* Author instance data may have zero or more foaf:givenName with Literal value type xsd:string *Line 6:* Author instance data may have zero or more foaf:familyName with Literal value type xsd:string *Line 7:* Author instance data must have rdf:type of foaf:Person Possibly Lines 4 and 7 could also be interpreted as "Book/Author instance data is that data which has rdf:type sdo:Book / foaf:Person" otherwise how would we know what was Book instance data? In which case it seems a simple non-extended TAP cannot cope with different shapes for different types of Book. Example Instance Data A reasonably complete & conforming instance would be: ***@***.*** dct: <http://purl.org/dc/terms/> # DCMI Metadata Terms @Prefix foaf: <http://xmlns.com/foaf/0.1/> # Friend of a Friend @Prefix sdo: <https://schema.org/> # Schema.org @Prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> # RDF @Prefix xsd: <http://www.w3.org/2001/XMLSchema#> # XSD: use for data types <https://www.wikidata.org/entity/Q19870535> a sdo:Book ; dct:title "A Book of Mediterranean ***@***.*** ; dct:creator <https://www.wikidata.org/entity/Q4944293> ; sdo:isbn "0123456789123"^^xsd:string . <https://www.wikidata.org/entity/Q4944293> a foaf:Person ; foaf:givenName "Elizabeth"^^xsd:string foaf:familyName "David"^^xsd:string | Noting that only rdf:type and dct:title (lines 1, 4 and 7) are mandatory, the simplest conforming instance is something like |# omitting @Prefix terms for brevity _:b0 a sdo:Book; dct:title "A Book of Mediterranean ***@***.*** . _:b1 a foaf:Person . | I think it is unexpected that there must be a a foaf:Person, even though there is no property pointing to it. This is a consequence of using and mandatory rdf:type to say that authors must be foaf:people. I don't see any way of saying whether a "top level" object (i.e. a node with no incoming arcs) should or should not be a blank node. Repeating properties in fully open profiles Repeating the title langstring is forbidden (line 1) so this fragment does not seem to match the intent of the profile: |_:b0 dct:title "A Book of Mediterranean ***@***.*** , "Un libro de comida ***@***.*** . | Assuming an open profile this example would match as only one statement matches line 1. |_:b0 dct:title "A Book of Mediterranean Food"^^xsd:string, "Un libro de comida ***@***.*** | But what really is the difference between these two examples? they both have one statement that matches line 1 and one that doesn't. Does this mean that in an open profile all properties are effectively repeatable? Likewise, (in and open profile) this is not forbidded even though it does not match the intent of the profile: |_:b0 sdo:isbn "123456789"^^xsd:string . | as is |_:b0 sdo:isbn "123456789"^^xsd:string , "1234567890123"^^xsd:string . | — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#55>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAL53YJHVFFDNX4C46COCT3UH7Y5RANCNFSM5GN3VUUA>.

-- Karen Coyle ***@***.*** http://kcoyle.net

[philbarker]

Thanks Karen, I've put this example (tap and conforming instance) in the examples folder under simple-book.

[kcoyle]

For this:

But what really is the difference between these two examples? they both have one statement that matches line 1 and one that doesn't. Does this mean that in an open profile all properties are effectively repeatable?

I would say no to that, but I think it is up to the ingesting application whether it will allow this. I see a difference between properties that have been included in a TAP and that have constraints (which I would apply to all instances of the property) and properties that haven't been included in the TAP and therefore you have no constraints to apply to them. By allowing all metadata statements that do not conform the TAP to be accepted you have essentially nullified the TAP.

[philbarker]

Yes, my instinct is the same: it seems against the grain of what an AP does. However, I think that "allowing all metadata statements that do not conform to the TAP to be accepted" is essentially what an open profile does. An open profile may say certain things (data matching shapes) must be present, but there's no way of forbidding other things.

[philbarker]

PS perhaps this is one of those places where it is better to speak of "matching" the TAP rather than "conforming": anything that doesn't match a statement in the application profile is allowed by an open profile.

[kcoyle]

It occurred to me that one use for an open profile would be as a way to investigate foreign data. You could get statistics on whether the foreign data matches your profile and on the ways in which it does not match. The profile would be treated as open because you want to sample the entire foreign metadata, not reject it for not conforming.