Difference between revisions of "ac:hasServiceAccessPoint"

From TDWG Terms Wiki
Jump to: navigation, search
(Refactoring existing definitions fromAudubon_Core_Term_List_(1.0_normative) to individual pages (automatic import through xml file))
 
(fixed newline issue)
 
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
__NOINDEX__
 +
<span style="background-color:#ffc; padding:5px; color:#f00;border:1px solid #f00;">'''Warning''': This is not the current version of this document. It is kept for archival purposes. For up-to-date information, go to https://tdwg.github.io/ac/termlist/#ac_hasServiceAccessPoint</span><br /><br />
 +
 +
 
{{Concept
 
{{Concept
| is defined by = ac:hasServiceAccessPoint
+
|label=Service Access Point
| label = Access Point
+
|definition=In a chosen serialization (RDF, XML Schema, etc.) the potentially multiple service access points (e.g. for different resolutions of an image) might be provided in a referenced or in a nested object. This property identifies one such access point. That is, each of potentially multiple values of hasServiceAccessPoint identifies a set of representation-dependent metadata using the properties defined under the section '''[[Audubon Core Term List#Service Access Point Vocabulary|Service Access Point Vocabulary]]'''.
| label = Service Access Point
+
|notes='''Audubon Core:''' Some serializations may flatten the model of service-access points by (a) dropping ac:hasServiceAccessPoint, ac:variant and ac:variantDescription, (b) repeating the properties of the Service Access Point Vocabulary and prefixing them with values of ac:variant. If such a flat serialization is necessary for services, we recommend to select from among terms of the form "AB" where "A" is one of thumbnail, trailer, lowerQuality, mediumQuality, goodQuality, bestQuality, offline and "B" is one of AccessURI, Format, Extent, FurtherInformationURL, LicensingException, ServiceExpectation (example: thumbnailAccessURI).
| definition = Reference to an object (the "access point")  describing network access to the media resource, or related resource, that the AC metadata describes. What constitutes an object is dependent on the representation (e.g., XML Schema, RDF, etc.), but for full compliance such a representation must provide that any of the terms in the '''[[Audubon_Core_Term_List#Service_Access_Point_Properties | Service Access Point Terms section]]''' below can be applied to an access point.
+
| notes = <b>Audubon Core:</b> hasServiceAccessPoint is an attribute of the media being described, as are all other AC terms except those in the following section, which are properties of the access point object referenced by the Service Access Point. Depending on the specific model used, the value of hasServiceAccessPoint may be implemented through some form of nesting objects inside other objects, or through a unique identifier pointing to an access point object.
+
  
Use with the '''[[Audubon_Core_Term_List#Service_Access_Point_Properties | Access Level Terms]]''' below. In particular, there is little point to using hasServiceAccessPoint if there is  no value for the Access URI and perhaps the dcterms:format. Implementers in specific constraint languages such as XML Schema or RDF may wish to make those two properties mandatory on instances.
+
Implementers in specific constraint languages such as XML Schema or RDF may wish to make Access URI and perhaps  dcterms:format mandatory on instances of the service access point.
| hidden notes = // Repeatable = Yes
+
|is defined by={{ACTERMLIST}}#ac:hasServiceAccessPoint <!-- for ac at least, this pagename is also the term name -->
 +
|concept type=property
 +
|hidden notes=// Repeatable = Yes
 +
}}
 +
{{Concept scheme relation
 +
|scheme=Audubon Core Development
 +
}}
 +
{{Concept relation
 +
|relation=skos: collection
 +
|internal page=Audubon Core Management  Vocabulary
 +
}}
 +
{{Concept relation
 +
|relation=skos: collection
 +
|internal page=Audubon Core Layer 1
 
}}
 
}}
{{Concept relation|relation = skos: in scheme |internal page = Audubon Core}}
 
{{Concept relation|relation = skos: collection|internal page = Audubon Core Record-level Service Access Point Vocabulary}}
 
{{Concept relation|relation = skos: collection|internal page = Audubon Core Layer 1}}
 

Latest revision as of 13:04, 5 March 2020

Warning: This is not the current version of this document. It is kept for archival purposes. For up-to-date information, go to https://tdwg.github.io/ac/termlist/#ac_hasServiceAccessPoint

Scheme: Audubon Core Development Pencil.png
Collections: Audubon Core Management Vocabulary Pencil.png, Audubon Core Layer 1 Pencil.png
Service Access Point
No type definition was found for "hasServiceAccessPoint" in the ac import.
Search for values Crystal Clear action find.png
Service Access Point: In a chosen serialization (RDF, XML Schema, etc.) the potentially multiple service access points (e.g. for different resolutions of an image) might be provided in a referenced or in a nested object. This property identifies one such access point. That is, each of potentially multiple values of hasServiceAccessPoint identifies a set of representation-dependent metadata using the properties defined under the section Service Access Point Vocabulary.

Notes: Audubon Core: Some serializations may flatten the model of service-access points by (a) dropping ac:hasServiceAccessPoint, ac:variant and ac:variantDescription, (b) repeating the properties of the Service Access Point Vocabulary and prefixing them with values of ac:variant. If such a flat serialization is necessary for services, we recommend to select from among terms of the form "AB" where "A" is one of thumbnail, trailer, lowerQuality, mediumQuality, goodQuality, bestQuality, offline and "B" is one of AccessURI, Format, Extent, FurtherInformationURL, LicensingException, ServiceExpectation (example: thumbnailAccessURI).

Implementers in specific constraint languages such as XML Schema or RDF may wish to make Access URI and perhaps dcterms:format mandatory on instances of the service access point.