ServiceAccessPoint

→ Information about submission as TDWG standard
→ MRTG Wiki Homepage
→ Current Schema Draft. This version is under internal review as part of the submission to TDWG.
→ Audubon Core Non normative document
→ MRTG Development History
→ MRTG Meeting Notes
→ MRTG Best Practices
→ XML Schema representation of Audubon Core
→ RDF representation of Audubon Core
→ MediaWiki Help

User:JoseCuadra and User:BobMorris believe that the Service Access Point structure is not quite correct.

1 Should there be a class at all

There are two reasons that MRTG might have a class instead of just properties that are applied to a class named something like MRTG_Resource and one reason it should not.

The reason it should not is stated in the MRTG terminology section, in which, following Dublin Core we said:

"A Class is a term that has a set of Properties. Thus, the values of the properties in this set define what it means for a resource (whether multimedia or not) to be a member of the class.. Typically if M is a resource and C is a class, we say "M is a C". We attempt to minimize the number of classes, because we want to support simple serializations, notably text files such as "Comma Separated Values" (CSV), in which structured representation is cumbersome or impossible."

The only Class on v0.7 is MRTG_Schema_v0.7#Class:_ServiceAccessPoint. A  !ServiceAccessPoint is itself complex in that unlike other properties of a MediaResource, a ServiceAccessPoint itself has some properties, including what does it describe (e.g. full image, thumbnail, etc.; the size of the object at the URL; ...).

An instance of a ServiceAccessPoint class would have all of these as properties, and several instances could be attached to a resource, which might have different access points for each of say, different resolutions. The various properties of an access point are thus gathered together by the instance. But note that several other MRTG Properties need such linking, e.g. Reviewer Name with Reviewer Comment, and we do not require a class to do so. In both RDF and XML-Schema there are one or more ways to model these linkages and we should be consistent, only using a Class where it makes sense. The task is simple in RDF using rdf:About. In XML-Schema, a Complex Type is probably needed. In any case, a CSV representation needs thought---possibly use some kind representation of linked CSV files.

The main thing that distinguishes access points from those other needs for links is the complexity of the structure. However, each property still need only link to one thing, the given access point itself.

2 Where do the properties belong

The Service Access Point Vocabulary begins with a set of named "Service Access Point Properties" but they do not seem to be properties (what kind of values have they?) so much as mutually exclusive(?) values of a property of the given access point, perhaps named AccessPointType. The mutual exclusivity has to be settled because if it holds, the property could be defined as an enumeration with unique value, and this would perhaps make XML Schema representation easier because the value can be an XML attribute. The cost of this is requiring multiple access points with the same URL if something can have both of those values. I'm not sure whether this is important.

User:BobMorris believes that all of the things called Service Access Point Properties should include the items that follow the Service Access Point Class Item, and that these should be specified as usable only in an instance of the Service Access Point Class.