TG2-ISSUE_ANNOTATION_NOTEMPTY

[iDigBioBot]

TestField	Value
GUID	fecaa8a3-bbd8-4c5a-a424-13c37c4bb7b1
Label	ISSUE_ANNOTATION_NOTEMPTY
Description	Are there any annotations associated with the record?
TestType	Issue
Darwin Core Class	All
Information Elements ActedUpon
Information Elements Consulted	AllDarwinCoreTerms
Expected Response	EXTERNAL_PREREQUISITES_NOT_MET if bdq:annotationSystem is not available; POTENTIAL_ISSUE if an annotation in bdq:annotationSystem exists with a matching bdq:annotationAlertIf; otherwise NOT_ISSUE.
Data Quality Dimension	Reliability
Term-Actions	ANNOTATION_NOTEMPTY
Parameter(s)	bdq:annotationSystem
bdq:annotationAlertIf
Source Authority	bdq:annotationSystem default = "W3C Web Annotation" {[https://www.w3.org/annotation/]} {"oa:Annotation vocabulary" {[https://www.w3.org/TR/annotation-vocab/]}
	bdq:annotationAlertIf default = "oa:Annotation with oa:hasTarget having as object any dwciri:term instance that is part of the SingleRecord under test." {[https://www.w3.org/TR/annotation-vocab/]}
Specification Last Updated	2023-09-17
Examples	[bdq:annotationAlertIf="": Response.status=RUN_HAS_RESULT, Response.result=NOT_ISSUE, Response.comment="bdq:annotationAlertIf is EMPTY"]
	[bdq:annotationAlertIf="?": Response.status=RUN_HAS_RESULT, Response.result=POTENTIAL_ISSUE, Response.comment="bdq:annotationAlertIf is not EMPTY"]
Source	ALA, Lee Belbin
References	W3C Web annotation Data Model: https://www.w3.org/TR/annotation-model/
	W3C Web Annotation Vocabulary: https://www.w3.org/TR/annotation-vocab/#annotation
	TDWG Annotations Interest Group [https://www.tdwg.org/community/annotations/]
Example Implementations (Mechanisms)
Link to Specification Source Code
Notes	While there is a W3C standard on 'web annotation', there is no TDWG recommendation on how this standard could be applied to annotating Darwin Core records. While implementation of this test is currently problematic, TG2 considers annotations attached to any aspect of a Darwin Core record justifies this test as a placeholder in the hope of future developments.

[iDigBioBot]

Comment by Lee Belbin (@Tasilee) migrated from spreadsheet: Paul reminded me that assertions are annotations that reminded me that we needed a flag for any user annotations

[iDigBioBot]

Comment by Paula Zermoglio (@pzermoglio) migrated from spreadsheet: I see two issues here: 1. annotations are not part of the record are are aggregator-dependent, and 2. the annotation does not necessarily mean sth wrong was found in the record, it might be a corroboration of what's in the record, and hence it'd be tricky to assess data quality from a "has annot" approach.

[iDigBioBot]

Comment by Arthur Chapman (@ArthurChapman) migrated from spreadsheet: Worth noting that we are not just flagging something that is "wrong" but warning users that there is something there they may wish to take into account in deciding what records to use. Also important for transferring from one aggregator to another and feed back to custodians of the data

[iDigBioBot]

Comment by Paul Morris (@chicoreus) migrated from spreadsheet: Feels like a plausible measure: the annotation store(s) of which the mechanism are aware contain one or more annotations where the occurrenceID is a subject of the annotation. Different mechanisms or the same mechanism with different configurations will produce different results.

[iDigBioBot]

Comment by Arthur Chapman (@ArthurChapman) migrated from spreadsheet: This is a worthwhile Annotation - but probably not a test that leads to an assertion. I am not sure how best to handle this in the terms of the tests and assertions

[iDigBioBot]

Comment by Lee Belbin (@Tasilee) migrated from spreadsheet: Sorry guys but this one IS MANDATORY - we are flagging if anyone has made an annotation about the record and we therefore have an obligation to expose that to all

[Tasilee]

To align with the response from other notifications, suggest changing to TG2-NOTIFICATION_ANNOTATION_NOTEMPTY

[ianengelbrecht]

Help with thoughts around implementation please. Would I include an annotations property in a dataset to record any annotations, such as confirmations of out of range species records? What would that property be called? dataAnnotations, dataQualityAnnotations? Many thanks.

[Tasilee]

First up, all the tests/assertions are at the record-level. You simply accumulate record-level responses for any dataset. Regarding annotations, see https://github.com/tdwg/bdq/issues/142 and https://github.com/tdwg/bdq/issues/149 but we do have a problem right now as @chicoreus has taken over chairing the TAG leaving a leader for the Annotations Interest Group vacant (https://www.tdwg.org/community/annotations/). I believe there was general agreement that TDWG would follow https://www.w3.org/annotation/.

The push for this 'assertion' comes from me given my experience with https://www.ala.org.au/uncategorised/annotations-alerts-about-new-annotations-and-annotations-of-interest/. My point was (as noted above) - if a user has 'flagged' something about a record, I figure you would want to know about it (and any subsequent 'actions'). The hassle is of course, that there is no standard on how annotations are handled. In the ALA's case, they are stripped off records when data is sent to GBIF.

@chicoreus : Any comment?

[ArthurChapman]

@Tasilee I have copied this to the Annotations GitHub (https://github.com/tdwg/annotations/issues/4#). This issue on the Annotations GitHub (Compile information on Feedback Mechanisms for Data Quality Interest Group) was raised by @chicoreus is to deal with the TG2 issues

[Tasilee]

Thanks @ArthurChapman

[Tasilee]

I've started to look at testdata for this NOTIFICATION and have made some changes/assumptions. I changed LABEL "PRESENT" to match title of test ("NOTEMPTY") and wonder about

1. The validity of Information elements "AllDarinCoreTerms". I would probably now opt for something like bdq:annotation and add it to the vocabulary. We are a step ahead of the relevant standard but I can't see why we shouldn't be more explicit here.
2. I'd opt for "NOTIFY if ..." rather than "REPORT if ..." in Expected response to match the title.

[Tasilee]

After zoom meeting, changed

POTENTIAL_ISSUE if annotations are not EMPTY; otherwise NO_ISSUE

to

POTENTIAL_ISSUE if annotations are not EMPTY; otherwise NOT_ISSUE

[Tasilee]

Are we really meaning "bdq:annotation" here? It obviously isn't "dwc:annotation" :).

@ArthurChapman and I are wondering why we would not have some Notes about this. I certainly understand the intent: If there is any annotation associated with the record, raise a flag....

[ArthurChapman]

Thinking about this and @chicoreus can comment on implementation - but I am not sure how this test would be implemented. In the Test data we have things like "bdq:annotation="anyOldTerm"" - but none of the databases we are checking will have a field called "bdq:annotation" will it? So what are we actually checking. I know what we are trying to do - but how does in work in practice. If the ALA adds an annotation, say on dwc:scientificName - it will be called something in the ALA database, but it WON'T be "bdq:annotation". Am I missing something here?

[chicoreus]

On Thu, 08 Jun 2023 15:06:46 -0700 Arthur Chapman @.***> wrote:

Thinking about this and @chicoreus can comment on implementation - but I am not sure how this test would be implemented. In the Test data we have things like "bdq:annotation="anyOldTerm"" - but none of the databases we are checking will have a field called "bdq:annotation" will it? So what are we actually checking.

Given Darwin Core data in a triple store, does a w3c annotation exist where the occurrenceID of the record under evaluation is found as the target of the annotation....

Thus not likely to be able to be implemented for most settings Darwin Core data is found in.

[Tasilee]

Let's discuss this on the next zoom (it has NEEDS WORK tag). My 5c worth is that we need to leave this test as CORE to encourage (prod?) Darwin Core and the Annotations Interest Group to figure how this test can be implemented. My experience with the ALA data (that has associated record annotations) strongly supports its value.

[ArthurChapman]

As above - this test has nothing to search for, and the examples are searching for "bdq:annotation" which won't be in any databases. The only way I can see this test working at the moment (after some rewording) is for the test to be Parameterized with the default parameter being the w3c "oa:annotation" - if field includes something - then it returns POTENTIAL_ISSUE, but if it is EMPTY of not in the database then it would return NOT_ISSUE. Individual implementers not using w3c would add in whatever their data model uses for annotations. Gradually over time (especially if the TDWG Annotations IG gets going again) more and more databases may begin to follow the W3C Annotation Data Model (https://www.w3.org/TR/2014/WD-annotation-model-20141211/)

[ArthurChapman]

I have added a definition of "bdq:annotation" in the Vocabulary (#152) which would then fit with my suggestion above of making the test Parameterized

"Optionally establishes if an Annotation exists in a Parameterized Test (q.v.) with the default being the w3c Annotations Data Model's "oa:annotation" | Parameter | Used in test "ANNOTATION_ISSUE_NOTEMPTY" (fecaa8a3-bbd8-4c5a-a424-13c37c4bb7b1)."

[chicoreus]

Three cases to consider for what is needed in a parameter to identify relevant annotations:

oa:annotation where the target is the dwc:occurrenceID

dwc:resourceRelationship where the darwin core object has a resource relationship of a type that expresses a relationship to an annotation.

ALA annotation related to the occurrence.

If we can work out how to parameterize these three cases we can probably generalize.

[tucotuco]

I'm a bit worried about Occurrence as a target of an Annotation. Is our target really limited to that? Some of our tests can be applied perfectly well to Events and Taxa.

[ArthurChapman]

I agree @tucotuco - the original aim was to look for an annotation anywhere - not easy thing to do if institutions aren't using the w3c annotations.

[chicoreus]

@tucotuco I concur. Typical CORE case is flat darwin core, but can be structured, and oa:target that has as its object any dwciri term that is part of the current SingleRecord (here the generality of the framework helps us, as we don't have to define what a SingleRecord looks like) is applicable. That could be phrased: there exists an oa:annotation where the target is any dwciri term found within the SingleRecord. That might get us on a path to a generalization: there exists an annotation that has a relationship to a term in the SingleRecord.

[Tasilee]

So what do we do? Expected response? Notes? Vocab?

POTENTIAL_ISSUE if an oa:annotation is not EMPTY; otherwise NOT_ISSUE ?

[chicoreus]

Let's try two parameters: bdq;annotationSystem and bdq:annotationCriteria

Then an expected response:

POTENTIAL_ISSUE if there exists an annotation in bdq:annotationSystem where bdq:annotationCriteria are met for the SingleRecord under test. otherwise, NOT_ISSUE;

A value for bdq;annotationSystem = oa:Annotation

A value for bdq:annotationCriteria = an annotation has oa:target as as its object any dwciri term found within the current SingleRecord.

We could probably phrase a reference to bdq:annotationSystem for ALA, and a similar bdq;annotationCriteria that operates to select relevant ALA annotations.

Don't think the phrasing is right, but this might be a starting point for working out a generalization.

[ArthurChapman]

I'd prefer not mentioning singleRecords in the Expected Response - we don't do it elsewhere, and for just this one test it would be good not to have >1 namespace term for the test if possible. Try this for a possible solution

As I suggested earlier if the test is Parameterized with bdq:annotation default = oa:annotation

POTENTIAL_ISSUE if bdq:annotation is not EMPTY indicating that an annotation exists in association with any dwciri term in the record; otherwise NOT_ISSUE

[Tasilee]

I like @ArthurChapman 's reasoning and suggestions. We would need to add dwciri reference/link and a concise Note on why we are doing this, and how we would at least like to see it work. As I am the 'pusher' on this 'test', I'm happy to write a sentence or two of plain English, but it will need @chicoreus and others to edit it into something else :)

BTW, I am still chasing ALA's current handling of annotations.

[ArthurChapman]

Perhaps we could get away from dwciri reference by saying

POTENTIAL_ISSUE if bdq:annotation is not EMPTY indicating that an annotation exists in association with any Darwin Core term in the record; otherwise NOT_ISSUE

If we cite dwciri, @tucotuco should be able to supply the best reference. Slide 8 in https://downloads.ctfassets.net/uo17ejk9rkwj/3Fg2Keqao8sMgKmwa0QWkC/1c8adb3f0658909cbaab2bb386361fca/Event_core_and_new_data_types_in_GBIF.pdf is worth looking at.

"The dwciri: namespace is intended for use exclusively with non-literal objects".

Is this something that should be added to the Vocabulary - or is just part of the Darwin Core system.

[chicoreus]

@ArthurChapman "record" is something that makes sense in terms of flat darwin core, but has no meaning within the terms of the framework, and here, where we are talking about annotations and OA, we are talking semantic web, not flat objects, and the boundary of a "record" is undefined. We need here to talk about the framework concept SingleRecord, all the other tests are doing so, as their scope within the framework is explicitly SingleRecord, not MultiRecord, but here, unlike other SingleRecord tests, we do need to mention the SingleRecord to be able to ask the question whether some annotation is about the SingleRecord at hand (which could be a flat darwin core record, or a structured star schema set of records in several tables, or an RDF graph), not about some other SingleRecord in the MultiRecord under evaluation. The framework divides the world into these two things as a specific generalization to avoid being limited to particular data structures.

@ArthurChapman we do not want to get away from referring to the dwciri namespace, the dwciri namespace is the thing that makes it easy for us to define if an oa annotation has a relationship to the current SingleRecord. If we don't reference dwciri, we will have a very difficult time listing which darwin core term in which data structures may represent boundaries.

[chicoreus]

@ArthurChapman the reference to use for dwciri is https://dwc.tdwg.org/rdf/

[chicoreus]

How about:

POTENTIAL_ISSUE if an annotation in bdq:annotationSystem exists matching bdq:annotationCriteria exits; otherwise NOT ISSUE.

bdq:annotationSystem default: oa:annotation

bdq;annotationCriteria default: exists an oa:annotation with oa:target having as object any dwciri:term instance that is part of the SingleRecord under test.

bdq:annotationSystem alternative: ALA annotations

bdq:annotationCriteria alternative: (not adequately specified) an annotation exists related to the SingleRecord under test.

[ArthurChapman]

Following @chicoreus's suggestion above - I have given this some thought and suggest the following:

Expected Response |POTENTIAL_ISSUE if an annotation in bdq:annotationSystem exists with a matching bdq:annotation; otherwise NOT ISSUE.

Parameter(s) | bdq:annotationSystem; bdq:annotation SourceAuthority | bdq:annotationSystem default = "ao:annotation"; bdq:annotation default = "oa:annotation with oa:target having as object any dwciri:term instance that is part of the SingleRecord under test."

Definitions for #152

bdq:annotation | Optionally establishes if an annotation exists within a bdq:annotationSystem (q.v.) in a Parameterized Test (q.v.). |

bdq:annotationSystem | Optionally established a system for annotations within a Parametereized Test (q.v.) with the default being the w3c Annotations Data Model's "oa:annotation". |

---

As an example where an annotation system is used other than the ao:annotations - for example the ALA (Atlas of Living Australia)

bdq:annotationSystem would = "ala:annotations" or whatever term they use. bdq:annotations would be whatever the ALA uses to detect an annotation (see https://www.ala.org.au/blogs-news/annotations-alerts-about-new-annotations-and-annotations-of-interest/)

[chicoreus]

@ArthurChapman I'd call bdq:annotation something like bdq:annotationSelectionCriteria to distinguish it from an ao:annotation, a {namespace}:annotation sounding like a type, rather than crieeria for finding whether an annotation exists. Calling it bdq:annotation has too much potential for confusion with an annotation.

[ArthurChapman]

OK - I agree with what you are saying, but not sure "bdq:annotationSelectionCriteria" is best term - any suggestion from others? . bdq:annotationValue . bdq.annotationAlert (fits with ALA) . other

[chicoreus]

On Fri, 23 Jun 2023 17:33:43 -0700 Arthur Chapman @.***> wrote:

bdq:annotationValue

Implies that this some value of the annotation rather than criteria for determining whether pertenent annotations exist.

bdq.annotationAlert (fits with ALA)

Matches to the result of the test, rather than the criteria to be applied in performing the test.

Could be a variant: bdq:annotationAlertIf that carries the connotation of criteria.

[ArthurChapman]

OK - basically the test is looking to see if there is any annotation - so question one is what system are you using (oa:annotation or something else ala:annotation, institution:alerts, etc.) and question 2 is under your system are there any annotations/alerts - if there are then it is not empty and there is a POTENTIAL_ISSUE - thus I don't see a problem with bdq:annotationAlert

[chicoreus]

On Fri, 23 Jun 2023 17:51:10 -0700 Arthur Chapman @.***> wrote:

OK - basically the test is looking to see if there is any annotation

• so question one is what system are you using (oa:annotation or something else ala:annotation, institution:alerts, etc.) and question 2 is under your system are there any annotations/alerts - if there are then it is not empty and there is a POTENTIAL_ISSUE - thus I don't see a problem with bdq:annotationAlert

The test is looking to see if an annotation exists in the specified annotation system meeting certain criteria, not if any annotation exists in the specified annotation system. Thus bdq:annotationAlert sounds like a synonym for ISSUE_ANNOTATION_NOTEMPTY, not the specification of the criteria by which pertenent annotations might be identified to raise a POTENTIAL_ISSUE from ISSUE_ANNOTATION_NOTEMPTY. Thus bdq:annotationAlertIf makes sense to me, bdq:annotationAlert does not. Using a term that sounds like it is describing the result of the test rather than the criteria by which the test would assertain a result reads to me like "POTENTIAL_ISSUE if an annotation in bdq:annotationSystem exists with a matching ISSUE_ANNOTATION_NOTEMPY; otherwise NOT ISSUE."

Try dropping the "with a" from the specification:

POTENTIAL_ISSUE if an annotation in bdq:annotationSystem exists matching bdq:annotationAlertIf; otherwise NOT ISSUE.

[ArthurChapman]

That's not my reading of the test - @Tasilee? The Tests is ISSUE_ANNOTATION_NOTEMPTY - not that an annotation meets certain criteria. My understanding is that we are testing if an annotation exists - basically are there any annotations anywhere within your annotation system for this record? If so, there is a POTENTIAL_ISSUE i.e. for this record is there any annotation within your annotation system - NOT_EMPTY - I don't see where any other criteria come into it.

[Tasilee]

I agree with @ArthurChapman: I simply want to know if ANY annotation exists about any aspect of the record. In our context, this means if anyone has said anything about any Darwin Core term, I want to know.

What annotation system is used, is implementation dependent. This would need to include "No annotation system is available" which would be, as far as I am concerned, an example of "EXTERNAL_PREREQUISITES_NOT_MET".

bdq:annotationAlert sounds nice bdq:annotationSystem ditto.

[chicoreus]

On Fri, 23 Jun 2023 19:14:21 -0700 Arthur Chapman @.***> wrote:

That's not my reading of the test - @Tasilee? The Tests is ISSUE_ANNOTATION_NOTEMPTY - not that an annotation meets certain criteria. My understanding is that we are testing if an annotation exists - basically are there any annotations anywhere within your annotation system for this record? If so, there is a POTENTIAL_ISSUE i.e. for this record is there any annotation within your annotation system - i.e. NOT_EMPTY - I don't see where any other criteria come into it.

For the test to return POSSIBLE_ISSUE, there must be criteria linking an annotation to the record under test.

Consider a triple store containing annotations and darwin core data. If no criteria are specified, the existence of any annotation in that triple store would cause this test to return POSSIBLE_ISSUE for every darwin core occurrence record tested, as some annotation exists.

The criteria are essential, they specify how an annotation in the data store may be considered to be related to the record under test. The criteria are not about the assertions in the annotation but about "for this record". The criteria specify how to determine if any annotation in the data store has a relationship to the record under test.

[chicoreus]

On Fri, 23 Jun 2023 19:20:24 -0700 Lee Belbin @.***> wrote:

I agree with @ArthurChapman: I simply want to know if ANY annotation exists about any aspect of the record. In our context, this means if anyone has said anything about any Darwin Core term, I want to know.

That is exactly the problem, you want to know if any annotation exist "about any aspect of the record", criteria for determining "any aspect of the record" are essential. If they are not present, what you get is "if ANY annotation exists", regardless of any relationship to the record.

Specifying oa:annotations as the annotation system is not sufficient, there also needs to be a specification of how an oa:annotation may be related to the record under test for it to be considered pertinent (and oa:annotation and dwc:occurrence both being children of a top level concept would not be desirable, or you are back to matching any annotation to all occurrences...).

[chicoreus]

On Fri, 23 Jun 2023 19:20:24 -0700 Lee Belbin @.***> wrote:

bdq:annotationAlert sounds nice

It does, but it sounds like a synonym for ISSUE_ANNOTATION_NOTEMPTY, leading to the test specification sounding like:

"POTENTIAL_ISSUE if an annotation in bdq:annotationSystem exists with a matching ISSUE_ANNOTATION_NOTEMPY; otherwise NOT ISSUE."

We need the specification to be something like:

"POTENTIAL_ISSUE if an annotation in bdq:annotationSystem exists matching {some criteria} that relate the annotation to the record under test; otherwise NOT ISSUE."

where it is clear that whatever parameter we specify for {some criteria} sounds like it is describing the criteria for relating annotations in the system to records, not like a synonym for an annotation or a synonym for the test.

bdq:annotationAlertIf sounds like it specifies criteria...

[Tasilee]

I would think something as simple as this?

"EXTERNAL_PREREQUISITES_NOT_MET if bdq:annotationSystem is EMPTY; POTENTIAL_ISSUE if an annotation is detected in bdq:annotationSystem; otherwise NOT ISSUE."

We don't need to reference a record as that is assumed for all tests.

[chicoreus]

On Fri, 23 Jun 2023 19:42:52 -0700 Lee Belbin @.***> wrote:

I would think something as simple as this?

"EXTERNAL_PREREQUISITES_NOT_MET if bdq:annotationSystem is EMPTY; POTENTIAL_ISSUE if an annotation is detected in bdq:annotationSystem; otherwise NOT ISSUE."

That is exactly the problem. With that specification, if ANY annotation existed in bdq:annotationSystem, then the test would return POTENTIAL_ISSUE for any record evaluated. The annotation could assert that a painting was by some artist, and any occurrence in the data set would evaluate this test as POTENTIAL_ISSUE.

The first clause is also entangling evaluating parameters values (which we aren't doing) with test specifications.

[Tasilee]

@chicoreus: "With that specification, if ANY annotation existed in bdq:annotationSystem, then the test would return POTENTIAL_ISSUE for any record evaluated" -

Yes, that is what I wanted. I see this as no difference from #58

[chicoreus]

On Fri, 23 Jun 2023 19:54:05 -0700 Lee Belbin @.***> wrote:

@chicoreus: "With that specification, if ANY annotation existed in bdq:annotationSystem, then the test would return POTENTIAL_ISSUE for any record evaluated" -

Yes, that is what I wanted. I see this as no difference from #58

No it is not what you want. Consider a triple store that contains triples making assertions about darwin core occurrances, and also containing a broader scope of information about other entities in the world, say out to the holdings of art museums (a likely case, as stores of linked open data can have wide scope). If this triple store contained one and only one annotation, and that annotation had as its target a record of a painting, with no biological content. The specification above would result in EVERY occurrence record in the triple store returning POTENTIAL_ISSUE - even though NONE of them have any annotation related to them in any meaningful way.

[ArthurChapman]

I am still not sure 100% of @chicoreus argument, but what I think he is saying is that the annotations may not be stored as part of each record but in a separate annotations store. But if that is the case, then there must still be a link back to the record.

With the ALA for example - you can annotate a record as one of a number of types: Geospatial, taxonomic issue, taxon misidentified, suspected outlier, biosecurity issue etc. - then you can add a note. So you may put a note under Geospatial saying the location is wrong etc. That will add a Flag to the record that says there is an annotation. (see https://www.ala.org.au/blogs-news/annotations-alerts-about-new-annotations-and-annotations-of-interest/)

All we want to know is for this record is the a flag - I don't care what the flag is, just that there is a flag, and if there is a flag then there is a POTENTIAL_ISSUE.

I can go into the ALA Alerts system and see what the current status is of any annotation I have added . The data provider can do the same thing - so the curators can bring up any alerts that relate to them or their institution.

So it doesn't matter what the annotation is, there is a flag on the record and that is all we want to know - i.e. for this record is there an annotation anywhere i.e. a POTENTIAL_ISSUE wrt to this record (doesn't matter if it is geographic, taxonomic or something else) - it may not even be related to any of the DwC terms that we test elsewhere as the flag may be that there is a biosecurity issue with this record. In many ways, it is totally unrelated to all our other tests.

So to me, all we are asking is "in the annotation system being used (set by the Parameter) is there a flag/annotation associated with this record?" - i.e. is it NOTEMPTY - if it is NOTEMPTY we flag a POTENTIAL_ISSUE.

[ArthurChapman]

To summarise comments above and various emails - I think we are heading to.

Expected Response | EXTERNAL_PREREQUISITES_NOT_MET if bdq:annotationSystem is EMPTY; POTENTIAL_ISSUE if an annotation in bdq:annotationSystem exists with a matching bdq:annotationAlertIf; otherwise NOT ISSUE.

Parameter(s) | bdq:annotationSystem; bdq:annotationAlertIf

SourceAuthority | bdq:annotationSystem default = "ao:annotation" | | | bdq:annotationAlertIf default = "oa:annotation with oa:target having as object any dwciri:term instance that is part of the SingleRecord under test."|

Definitions for https://github.com/tdwg/bdq/issues/152

bdq:annotationAlertIf | Optionally establishes if an annotation exists within a bdq:annotationSystem (q.v.) by describing the criteria for relating annotations in the system to records in a Parameterized Test (q.v.). |

bdq:annotationSystem | Optionally established a system for annotations within a Parametereized Test (q.v.) with the default being the w3c Annotations Data Model's "oa:annotation". |

@chicoreus - does this make it implementable? Also check definition of bdq:annotationAlertIf

[chicoreus]

@ArthurChapman that's looking good. That should be enough for implementors to work with for either systems holding oa:annotation, or to work out parameter values and implement for other systems (such as ALA). MCZbase supports annotations (in its own internals, not wholly aligned with the web annotation vocabulary), so I can take a shot at implementing for that, and can try framing the annotationAlertIf as a sparql query.

Not sure about "EXTERNAL_PREREQUISITES_NOT_MET if bdq:annotationSystem is EMPTY;", we've been avoiding evaluating the values of parameters to determine test results, substitute "not available" for EMPTY, and that becomes consistent with other tests.

[ArthurChapman]

Yes - it should be "unavailable"

Updated Expected Response, Parameter(s), Source Authority, Specification Last Updated and Examples

@Tasilee - check - especially Examples. I think the notes are OK. If OK you can remove NEEDS WORK I will update #152.