This page collects open issues related to the API specification.

Issues to be discussed

Return types

cardinalities

• which properties should return a collection of values, esp. if there are different roles, and in general there might be different language versions [1], [2]

• for those returning a list of values, how to deal with the filters proposed in the Strawman API design and notes

• for those returning list of values, use plural [3]

free text vs. formal values

• this is an addition dimension to structured/unstructured, e.g. there could be both a structured and unstructured person name, but also a FOAF URI, similar issues exist for identifiers of roles or licenses [4], [5]

• it should be possible for programs using the API to unambiguously recongnize that they got a free-text string or a URI (or handling the URI case will be error-prone and cumbersome, and users will not do it). This can be done by a convention on string format or a structured type [6].

• see also list of role/subtype identifiers below

list of role/subtype identifiers

• should be added to the API specification [7]

representation of dates

• there is no consensus for the moment in the Web IDL WG on the representation of dates. We should there fore propose our own representation. However, as much as possible, we should keep the way open to the standardized way once it exists. A solution could be for example to define a structured type, with one attribute being the equivalent representation using the (future) standard.

Resolved issues, not yet implemented in API document

duration

• it is not certain that all temporal units can be converted to seconds; hence is it safe to force the return value of ma:duration to be expressed in seconds?
• furthermore, it would be nice to support same ways of specifying time as in MFWG temporal fragments [8]
• DECISION at F2F 2009-11-05: support NPT as used in MFWG, i.e. seconds as floating point values

list of role/subtype identifiers

• defined role/subtypes identifiers should preferably be URIs than plain text [9].
• DECISION at F2F 2009-11-05: both URIs and free text must be supported

data type definitions

• should be put into the API document (possibly add range definitions for the properties to the ontology document)
• DECISION at F2F 2009-11-05: keep in ontology document, as summary table documents data types of our set of properties