XCRI CAP 1.0 Issues List
From Xcri
| ID | Issue | Description | Proposed resolution | Importance | Added By | Status |
|---|---|---|---|---|---|---|
| 5 | Cost has ambiguous values | Should cost have more indicative values, or an encoding? Currently its purely descriptive. | ! | Scott | TBD | |
| 7 | Course events | Nothing for events in a course | Add an item to the presentation description vocabulary for 'course events' enabling use of hCalendar | !! | OUCS | TBD |
| 8 | Ambiguity of address data and usage? | Unclear about what is and isn't about geocoding, whether to duplicate address elements for display? Use of name? | Add additional guidance material on address usage | !!! | OUCS | TBD |
| 9 | Multi-provider records, and internal aggregation | Guidance is missing on cases where there are multiple providers gathered together as a single feed, e.g. OUCS | Add additional guidance material | !! | OUCS | TBD |
| 10 | Including elements from other namespaces | Currently only DCES, should this be wider? E.g. DCTERMS, or just "any" | ! | Scott Wilson | TBD | |
| 11 | Use of vocabulary encoding schemes | Should things like the course description type be separately bound as a recommended vocabulary, to enable use of other terms by providers? | ! | Scott Wilson | TBD | |
| 12 | Attendance information | Need to be able to filter by type of attendance (e.g distance) and by pattern (e.g. evenings) | ! | Scott Wilson | Added strawman elements to Presentation | |
| 13 | Course.description | Course.description is mandatory in CAP XSD but doc/annotation says optional; should be optional. | Fix the XSD and make sure documentation in wiki matches clearly | ! | Alan Paull | To Fix In 1.1 |
| 14 | Course.qualification | (Alan)...Is mandatory, perhaps shouldn't be? (Scott) No, it shouldn't be. The spec says "multiple" (i.e. 0..1). I'll open a ticket for this; not all courses lead to qualifications. | Fix the XSD and make sure documentation in wiki matches clearly | ! | Alan Paull | To Fix In 1.1 |
| 15 | Catalog metadata | Currently no metadata for catalog, not even title or summary, though this would be useful where several providers are offered in a single catalog, or catalog is a result of a query, to echo the query parameters | Enable the same basic dc-style metadata for catalog as for other resources, such as Provider and Course | ! | Sebastian Rahtz | To Fix In 1.1 |
| 16 | Advertise-from date | Currently there is no indication for paper publications when to advertise a course from, though this could potentially be inferred from presentation start and end dates | Include an optional advertise-from date | ! | Alan Paull | TBD |
| 17 | Qualification metadata | Currently no metadata for qualification | As with Seb's suggestion for catalog, make qualification an extension of the superclass that carries dc-style metadata | ! | Mark Stubbs | To Fix In 1.1 |
| 18 | Guidance on multiple identifiers | Aggregators have assigned their own identifers to courses offered by institutions | Scott's resolution 1 has enabled multiple identifiers. Clear guidance is needed to encourage institutions to create definitive, provider-controlled identifiers for courses and presentations (ideally resolvable urls), with the opportunity to add other identifiers as 'hints' for the benefits of aggregators | ! | Mark Stubbs | To address through guidance |
| CAP 1.0/1 | Presentations with no specific start date : how do we deal with presentations with no specific start date e.g. CPD courses which say ‘start at any time’? These courses can be studied at any time between two dates; for example there may be a 26 month 'window' during which you can register and make your final submission, but the course is only 30 hours of study time. | Possibly make optional with absence = "anytime" | ! | Alan Paull | TBD | |
| CAP 1.0/2 | Summer school : How do you use XCRI CAP to represent a summer school (with dates) within a course which has much longer dates? In these examples, the course consists of some pre summer school work, the summer school itself and an assessment after the summer school. So there are elements of distance learning and face-to-face. | ! | Alan Paull | TBD | ||
| CAP 1.0/3 | Courses which are just a summer school : How do we represent courses which are just a summer school? These summer schools are usually 1 week and have to be taken during a two month window; so they are 1 week face-to-face, but start dates and locations are variable. | ! | Alan Paull | TBD | ||
| CAP 1.0/4 | Relationship between qualifications and courses : what mandatory bits should there be? | ! | Alan Paull | TBD | ||
| CAP 1.0/5 | XHTML : Use of XHTML in description elements may cause implementation issues. | This may well be the only solution to supply of descriptive text. However, few systems of data collecting organisations currently use XHTML for this and few provider systems hold their descriptive data in this format. Use of XHTML may require sizeable changes to content management systems. Implications for authoring, transformations and storage. | ! | Alan Paull | TBD | |
| CAP 1.0/6 | identifier : No attribute to state what the identifier is. | Now changed re identifierDType | ! | Alan Paull | TBD | |
| CAP 1.0/7 | provider.name : Type of name is not prescribed; it could be official name or trading name or a name used to help sorting; for example "The Open University" (official and trading name) versus "OPEN UNIVERSITY (THE)" (as held on learndirect) | Critical if name is used as a primary identifier (which it shouldn't be). | ! | Alan Paull | TBD | |
| CAP 1.0/8 | provider.addressGroup.street : Mandatory. OU has a PO Box not street. Clash is between address as a postal location and a geographical location. Especially as OU students do not have campus-based tuition. | Make street not mandatory? | ! | Alan Paull | TBD | |
| CAP 1.0/9 | MIAP policy on attributes : Attributes shall not be defined globally, but defined locally to the element where they are used, using a globally defined simple type. | I believe that only recstatus breaks this policy. Suggest amend to fit in, using a recstatusType. | ! | Alan Paull | TBD | |
| CAP 1.0/10 | MIAP IDs in Schemas : The id attribute shall be used to show the CDD identifier. Where an element is defined globally, the id shall be used in the element definition. Where the identifier applies to an attribute, the id may be used in the definition of the simple data used by the attribute definition. | "Suggest we consider use CDD as a source of a vocabulary of IDs; for example: <provider id=""CDD:001 020"">. This would require addition of ID attributes to elements covered by the CDD; might help with future interoperability; for example, the organisationDType would need an ID attribute.
Caution: These are IDs for the CDD, not IDs for the provider!" | ! | Alan Paull | TBD | |
| CAP 1.0/11 | Address format issue : MIAP is no help. UKRLP format is not a recommended MIAP format. We should investigate what bits are mandatory. | Probably best to ignore this, because it doesn't look implementable. | ! | Alan Paull | TBD | |
| CAP 1.0/12 | course.description@type vocabulary : Some vocabs should be recommended but external and imported? | I would prefer all vocabularies to be external to CAP, so that maintenance of vocabularies does not interfere with the CAP schema. | ! | Alan Paull | TBD | |
| CAP 1.0/13 | course.description : Is mandatory in CAP but annotation says optional; should be optional. | ! | Alan Paull | TBD | ||
| CAP 1.0/14 | course.xs:any : Is mandatory in latest CAP but annotation says optional; should be optional. | Unfortunately Altova MapForce doesn't support xs:any ! | ! | Alan Paull | TBD | |
| CAP 1.0/15 | faculty / school in CAP? : Where? | Is it worth adding in (as in big xcri) a child organisation to the OrganisationDType? | ! | Alan Paull | TBD | |
| CAP 1.0/16 | course.qualification : Is mandatory, perhaps shouldn't be, because not all courses are qualification bearing. | This one might have to have local variation, because qualification records are mandatory for some data collecting organisations. However, I would say that this lies on the data collecting organisation's side of the processing, not XCRI CAP. | ! | Alan Paull | TBD | |
| CAP 1.0/17 | qualification.level : Course level (for example Level 0, 1, 2, 3 at undergrad HE) is very important for articulation of course components and progression. Should be on a course as well as qualification, perhaps as part of a Credit Accumulation and Transfer structure. | Draft information model specification attached as cats.doc. | ! | Alan Paull | TBD | |
| CAP 1.0/18 | qualification title : Qualification titles are changed around to give the subject first and the qualification type afterwards when they are provided to aggregators as 'course' titles. When will this be done in the new system and by whom? | There is an implementation problem with respect to the definition and format of qualification title. Some organisations see qual title as, for example, "BA (Hons)"; others see it as "BA (Hons) in History"; others see it as "History BA (Hons)". The formatting issue can be left to the data collecting organisations, but the definitional one remains. | ! | Alan Paull | TBD | |
| CAP 1.0/19 | Courses offered every 2 years : Some courses are offered every 2 years, so are 'live' courses, but with no 'live' presentations. | For the OU we've decided not to make these live. However, others may wish to show provision as available but with no live presentations. | ! | Alan Paull | TBD | |
| CAP 1.0/20 | Email : Email element is in the information model as a conventional email address, but the OU implements a webmail URL | ! | Alan Paull | TBD | ||
| CAP 1.0/21 | CourseID to contain provider ID? : The recommendation for a CourseID in XCRI CAP is to use a persistent identifier, preferably a URI. Is it expected or desirable that this identifier should have a provider ID with it, for example "http://www.open.ac.uk/courses/12345"? | ! | Alan Paull | TBD | ||
| CAP 1.0/22 | Persistent course ID : Use of persistent URI for course ID is recommended, but currently not widely adopted. | Although the recommendation to use a persistent URI for course ID is admirable, there is the significant implementation problem that very very few organisations (any?) use this solution. Should we consider perhaps a proxy solution of promoting the learndirect permanent ID until such time as persistent URIs for courses have greater currency? | ! | Alan Paull | TBD | |
| CAP 1.0/23 | Responsibilities between provider and data collector : There is an issue regarding the responsibilities of provider, data collector and any agent; where are the boundaries of these responsibilities? For example, at the present time some data collectors insist or encourage providers to key to specific data entry or formatting standards. With an XCRI CAP web service, the provider could point the data collector to the data, but it might not meet the data collector's formatting or style requirements. The nature of the relationship changes. | Data collecting organisations are very likely to have to carry out their own transformations on XCRI CAP data before integrating it with the rest of their data. It is unlikely to satisfy their requirements in 'native' format. Contrast with current situation where all they have to do is validate material keyed into a web-based data input system with drop-downs (or alternatively they have to key the whole lot from prospectuses). | ! | Alan Paull | TBD | |
| CAP 1.0/24 | Future courses : Filtering by date, for example to obtain 'future courses' for paper publications to be published some time in the future. This suggests a requirement for visibleFrom and visibleUntil dates. | ! | Alan Paull | TBD | ||
| CAP 1.0/25 | Student Entry Profiles : XCRI CAP could usefully include a section on student entry profiles, structured in a way that is compatible with UCAS usage. | Draft information model specification attached as entryprofiles.doc. | ! | Alan Paull | TBD | |
| CAP 1.0/26 | Information about the provider : The provider often doesn't hold basic details about itself in a readily transferable form, for example in a database - usually a courses database will only have the courses, not the standard contact details on the provider. It's often on its own website, but not transferable. | Implementation must take this into account; the provider should make arrangements to provide this fairly static information, or alternatively some of it could be picked up from the UKRLP. | ! | Alan Paull | TBD | |
| CAP 1.0/27 | presentation.start : Currently mandatory, but in some provider systems the start date is not held, but rather the whole data set relates to one year of entry. What should we do with null data? | MIAP covers this by permitting null data with a coded reason as an attribute. This might be a constructive way of handling this issue. Data collecting organisations could then arrange for an appropriate default value if there was no data in the element. | ! | Alan Paull | TBD | |
| CAP 1.0/28 | presentation.applyTo : This element assumes that application will always be to a specific organisation. However, providers often give information about the application process (for example, "Apply via UCAS"; "Apply via our website"), rather than organisation details. | Perhaps this needs an option for descriptive text and the organisational detail also needs to be optional. | ! | Alan Paull | TBD |
See also: Category:Ambiguous definitions, Category:Pages that need to be completed, Category:Items needing examples
[edit] Resolved Issues
| ID | Issue | Description | Proposed resolution | Importance | Added By | Status |
|---|---|---|---|---|---|---|
| 1 | Identifier multiplicity and encodings | Many elements, such as providers and courses, need to have one or more third-party identifiers as well as their default URL identifier. This is currently indicated in the text, but not in the XSD binding. | Use IdentifierDType instead of xs:string, and change multiplicity of IdentifierDType to 1..* or 0..* | !!! | Scott | Implemented --scottwilson 12:01, 4 April 2007 (BST) |
| 2 | Localisation of Titles | Titles should be expressible in multiple languages | Title should use a "LabelDType" type that declares use of xml:lang, with 1..* or 0..* multiplicity | !! | Scott | Implemented --scottwilson 12:01, 4 April 2007 (BST) |
| 3 | Inheritability of ApplyTo | ApplyTo should be inheritable from provider, but is currently mandatory | Make ApplyTo 0..1 multiplicity | !! | Scott | Implemented --scottwilson 12:01, 4 April 2007 (BST) |
| 4 | Inheritability of Venue | Venue should be inheritable from provider, but is currently mandatory | Make Venue 0..* multiplicity | !! | Scott | Implemented --scottwilson 12:01, 4 April 2007 (BST) |
| 6 | DC import issues | Many processors can't handle the advanced QDC schema | Use the simpleDC schema using xs:any instead of dc:any | !!! | Scott | Implemented --scottwilson 12:01, 4 April 2007 (BST) |
