Difference between revisions of "ac:hasServiceAccessPoint"

Revision as of 09:29, 11 October 2012 (view source) Gregor Hagedorn (Talk | contribs) ← Older edit		Revision as of 21:48, 11 October 2012 (view source) Gregor Hagedorn (Talk | contribs) Newer edit →
Line 3:		Line 3:
	| label = Access Point		| label = Access Point
	| label = Service Access Point		| label = Service Access Point
−	| 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.	+	| 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 provides access to one such access point. That is, each of potentially multiple hasServiceAccessPoint provides a set of representation-dependent metadata using the properties defined in the '''[[Audubon Core Service Access Point Vocabulary]]'''.
−	| 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.	+	| notes = <b>Audubon Core:</b> 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).
−	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		| hidden notes = // Repeatable = Yes
	}}		}}

---

Revision as of 21:48, 11 October 2012

Scheme: Audubon Core Development 
Collections: Audubon Core Management Vocabulary , Audubon Core Layer 1 

Service Access Point No type definition was found for "hasServiceAccessPoint" in the ac import. URI: http://rs.tdwg.org/ac/terms/hasServiceAccessPoint is defined by ac:hasServiceAccessPoint

RDF feed | Browse properties |  Concept type not set. A property page exists already. Please set “Concept type = property”.

Search for values

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 provides access to one such access point. That is, each of potentially multiple hasServiceAccessPoint provides a set of representation-dependent metadata using the properties defined in the Audubon Core 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.