Add ac:ServiceAccessPoint class

[nielsklazenga]

This proposal is following up on the discussion we had during the business meeting at TDWG/SPNHC 2018 in Dunedin and the teleconference this morning (morning in Australia).

The ServiceAccessPoint class will be the range of the ac:hasServiceAccessPoint term in the Management Vocabulary and the domain of all the terms in the Service Access Point Vocabulary. The ServiceAccesssPoint class has a many-to-one relationship with the media resource – which is one of the Dublin Core types.

[baskaufs]

Just to clarify, TDWG doesn't formally declare range and domains for its terms when it mints them as part of its basic vocabularies. But as Niels is indicating, this proposal intends that the object (or value) of the ac:hasServiceAccessPoint property will be an instance of the ac:ServiceAccessPoint class, and that ac:ServiceAccessPoint instances will serve as the subjects of statements made using properties in the Service Access Point Vocabulary.

[baskaufs]

Formal proposal:

Term Name: ac:ServiceAccessPoint

Type: rdfs:Class

Label: Service Access Point Class

Required: No

Definition: A specific digital representation of a media resource.

Usage: This term serves as a type for values of the ac:hasServiceAccessPoint property.

Notes: For example, a Service Access Point may have a specific resolution, quality, or format.

[baskaufs]

Justification for the term addition: the existence of the class is implied in the description of the ac:hasServiceAccessPoint property and in the description of the Service Access Point vocabulary, but the actual class term itself is missing from the vocabulary.

[baskaufs]

During the 2019-08-29 Maintenance Group Call, the group approved moving forward a proposal to add the ac:ServiceAccessPoint class to Audubon Core.

The 30 day public comment period for this term addition begins on 2019-09-20 and will end on 2019-10-20. To comment on this proposal, comment on this issue. For more information on the vocabulary change process, see Section 3.3 of the TDWG Vocabulary Maintenance Specification.

[qgroom]

I find the description rather incomprehensible from a laypersons perspective.

"A specific digital representation of a media resource" Is this the name of a file e.g. picture.jpg ? Perhaps a unique identifier, such as a DOI or URL?

If this is a class what are the properties?

Perhaps this is obvious if you know more about Audobon Core, but I feel it could use a good example and a diagram.

[baskaufs]

@qgroom, If adopted, this term definition would fall within section 7.10 of the Audubon Core Term List document. That's the section entitled "Service Access Point Vocabulary". The beginning of that section has a description of what a Service Access Point is and the section lists the properties that would apply to ac:ServiceAccessPoint instances. So the term metadata listed above would not be expected to stand alone in the documentation.

Could you take a look at the text there and give some more feedback about whether you think the description would be inadequate in that context? The text preamble to that section hasn't been changed since adoption of the standard, but it isn't normative, so we could easily modify it to clarify things. In particular, we probably should state that the properties of that section can be applied to ac:ServiceAccessPoint instances. (I say "can" because the AC Structure document points out that it's possible to provide details about SAPs in a "flat" structure without having separate rows for each one -- essentially using the SAP properties directly with the parent resource.)

We could also add to the Notes property for the term if there is something succinct that would could add that would make things more clear.

[debpaul]

So @baskaufs, (echoing @qgroom's sentiments), does this mean, what you propose is to formally add a class - that in essence is already there (implied). But that this would give a formal way to declare different instances of "has service access point" and "what is at that access point" (information about quality, format, ...). Is that it? The need for concrete examples (through your link above to the AC Term List document) does help -- but trying to wrap our brains around the concepts -- using words -- instead of diagrams -- is hard.

[baskaufs]

Yes, @debpaul you have it right. The existence of the class is already implied in the documentation and by the fact that there is a whole list of properties that are applied to its instances (the Service Access Point Vocabulary terms). We are just proposing to make that existence explicit.

[debpaul]

Works for me.

[baskaufs]

I don't remember exactly what the reason was for not creating this class when AC was initially ratified. I think maybe it was because Bob Morris and his team were pretty adamant that there was no "official" serialization of AC - it was intended to be representation-independent. So although a Linked Data person might think having a separate class for ServiceAccessPoint (SAP) would be great, people who want very flat spreadsheets might not be interested in it at all.

The Structure document makes it clear in section 3.2 that it's fine to flatten things out so that the SAP properties are considered direct properties of the media item itself (see example 3.2.2). In that case, you wouldn't need to have an SAP instance at all. But for people who want to have a more normalized model, it might be desirable to have a separate SAP table and having the SAP class would allow them to specify what that table was "about".

I think the SAP class is similar to some of the DwC classes that are hard to describe because their real purpose is to enable one-to-many relationships as opposed to having some easily definable identity as a class. I think in the case of the SAP class, one can understand what an SAP is by looking at the properties in the Service Access Point Vocabulary. An SAP is something that can have an accessURI, has a format, has a PixelXDimension, etc. Specific digital representations of abstract images (e.g. image files) would fall into that category.

[baskaufs]

The specified date for the public comment period on this is over. However, if there isn't consensus, the public comment period should be held open until either there is a consensus or we give up. I am feeling like @qgroom's comments were really a request for better documentation rather than an issue with the term proposal itself. If that is true, then I think we can say that there is a consensus on the proposal, close the issue and move it on for executive approval. @qgroom, can you confirm this? I'll try to ask you in person at BiodiversityNext this week if I don't get a response here.

[baskaufs]

Quentin says that his issue is primarily with the documentation and not the proposal itself, so I'm closing the public comment period since I believe there is no expressed dissent to the proposal.

[baskaufs]

This change was approved by the Executive committee as of 2019-12-02