This report attempts to provide an overview of the current status of quality ratings frameworks as embodied by PICS and presented a range of usage scenarios that provide the motivation for future development of quality ratings frameworks within an RDF environment. The development of quality ratings vocabularies and the options for the implementation of quality-based services have been discussed.
This section provides an overview of current issues (problems) that have been identified within this report for developers of quality vocabularies and implementers of quality-based services. Finally, a number of scenarios that highlight these issues and provide potential directions for future work are presented.
Ratings are given from different points of view and for different purposes; with that as a premise it would be impractical to develop a single "quality vocabulary" to describe all usage scenarios - rather a modular approach should be taken drawing on and adding to efforts and initiatives taking place elsewhere.
It will be necessary to be able to describe not only the resources but also who is rating the resources and what their qualifications or reasons are for doing so. Again this will draw on work that is being developed outside of DESIRE in the area of collection descriptions, Dublin Core and the Vcard project.
Translation of existing quality ratings from PICS to enable their use in an RDF environment would require mappings from the commonly used PICS vocabularies to an appropriate DESIRE vocabulary suitable for representation in RDF.
During the transition period between PICS and RDF in may be necessary to deploy RDF ratings in terms of an existing PICS vocabulary. This would require a mapping from a DESIRE/RDF vocabulary to a standard PICS vocabulary.
A model of trust for quality ratings is required. Authenticity of resources may be established at the level of individual quality statements, complete quality ratings or at the level of a ratings bureau. In the former case the user of a rating must have a mechanism for establishing trust of individual ratings. In the latter case a user may decide to trust all ratings from a particular bureau (there is still the issue of establishing that the bureau is legitimate).
The example below first shows what a block of RDF on a "crank" site might look like, followed by a sketch of some sceptical RDF statements which are "aboutEach" of the assertions pointed to by URL. Note that all the RDF vocabularies used below are fictional, and that use of vocabularies is independent of the agency that defines them. The example shows cranks.net using a medical vocabulary to express claims about the powers of their products. This is all very much in the spirit of PICS labelling (http://www.w3.org/PICS/).
A note on syntax - These examples use the new XML namespaces mechanism to associate the use of a language with it's machine readable definition. For example, an attribute xmlns:skeptic="http://skeptic.org/vocab/" tells us that any elements or attributes prefixed with the name "skeptic", are drawn from the RDF vocabulary whose definition can be found at that address. The RDF Schema Specification Language is used to do this definition in a manner which will aid authoring, editing and indexing tools understand some of the constraints on the constructs defined in that vocabulary.
Example: Web of Distrust - Cranky Common Cold Cures magic lemonade advert
<!-- this RDF would be found on the catalogue pages of a fictional crank site on cranks.net and is intended to be indexed by RDF aware search robots -->
<RDF:RDF
xmlns:RDF = "http://www.w3.org/TR/WD-rdf-syntax/#"
xmlns:s = "http://commercevocab.org/schemas/products/#"
xmlns:MEDIC = http://www.respectablemedics.org/utilityvocab/#>
<RDF:Description about="http://cranks.net/coldcures/magic_lemonade/"
bagID="D_summer98" >
<s:product_description>
Our cold curing lemonade was the hit of summer '97. Align your karmic rays with lemon
power to fight off those pesky colds.
</s:product_description>
<MEDIC:medicinalProperties>
This Lemonade Cures Colds. Sound too good to be true?
</MEDIC:medicinalProperties>
</RDF:Description>
</RDF:RDF>
Meanwhile in another part of the Web...
<!-- this RDF makes assertions about the believability of the claims
made above, and provides a URL for evidence backing this up -->
<RDF:RDF
xmlns:BELIEF = "http://purl.org/rdf/beliefvocab/#"
xmlns:SKEPTIC = "http://www.skeptic.org/skepticalvocab/#"
xmlns:RDF = "http://www.w3.org/TR/WD-rdf-syntax/#"
xmlns:MEDIC = "http://www.respectablemedics.org/utilityvocab/#">
<RDF:Description
aboutEach="http://cranks.net/coldcures/rdfcatalogue#D_summer98">
<BELIEF:notBelievedBy> Doubting Thomas </BELIEF:notBelievedBy>
<SKEPTIC:knownFraud> True </SKEPTIC:knownFraud>
<SKEPTIC:refutedByDoc
resource="http://respectablemedjournal.org/jan1991/coldcurescrankfeature"/>
<MEDIC:accredited>False</MEDIC:accredited>
</RDF:Description>
</RDF:RDF>
It is necessary to be able to distinguish between the subjective ratings of end users and 'official' ratings provided by experienced cataloguers within recognised organisations. This is partially a vocabulary issue (how can the source of the rating be expressed) and may be partially handled by context. A subject gateway may clearly distinguish when subjective user ratings are being used and when the subject gateway's internal criteria are being used.
If quality criteria are to be used to automatically select and reject resources based on their quality then it is necessary to have a way of specifying the criteria on which to select or reject resources. This may be by requiring an exact match for certain criteria or by saying that the value for a particular attribute must be within a particular range (including above or below a certain value). PICS Rules should provide the basis for work in this area.
In order to use quality ratings to rank search results (or other lists of resources), it is necessary to be able to specify the quality criteria that should be used. In the simplest case results may be ranked according to a single quality attribute (such as number of citations for each resource). More complicated scenarios will require ranking according to multiple quality attributes and also standard search ordering criteria. PICS does not provide a mechanism for specifying comparison criteria.
One aspect missing from the PICS architecture was support for requests such as 'which bureaux have ratings for resource x'. Centroid technology provides a possible means of achieving such behaviour. This issue requires further investigation.
A number of scenarios require the use of ratings information with respect to user preferences (for example, ranking of search results). It must be possible to represent both filtering criteria and comparison criteria in a machine-readable format. If preferences are to be shared across multiple quality-based services then it must be possible for services to have shared access to user preferences.
Digital signing is an issue that is relevant to many applications of RDF. It is especially important when the RDF contains information relating to the quality of the resource.
RDF provides a mechanism for specifying that a description applies to a set of resources (such as all web pages with a certain URI prefix). A ratings bureau must be able to consider such information when returning ratings for a particular resource. This is also an issue when ratings are embedded or stored with resources.
This report has highlighted the issues that need to be considered in order to develop quality vocabularies and quality-based services in an RDF environment within the context of the DESIRE project. It has provided recommendations on handling these issues and indicated areas where further work is required.
A further DESIRE deliverable (D3.2) will develop a prototype quality ratings service. Clearly it will not be possible to address all quality-related issues or prototype all possible scenarios within D3.2. Here we present a number of scenarios that would illustrate the usage of quality rating in an RDF environment and which would further understanding of the various issues highlighted in this report.
1. Collaborative Rating Service - A collaborative rating service to allow end users to rate resources. At the browsing companion end this would require a mechanism for users to rate the resource they are currently viewing and a mechanism to see other users' ratings of the same resource. At the server end this would require a ratings bureau that could store individual ratings and serve RDF ratings for a particular resource. User authentication would be required to associate rating with users. The vocabulary could be generic or domain specific but should be simple enough for end users to rate resources.
2. Ranking of Subject Gateway Searches - An extension of an existing subject gateway service with ranking of results based on quality criteria. This would require a quality vocabulary suitable for the domain of the subject gateway. It would require a label bureau capable of serving ratings to the subject gateway service and optionally to third parties. It would be necessary to extend subject gateway software (such as ROADS) to rank search results based on standard or user defined quality criteria; it would also be necessary to consider how current ranking criteria can be combined with ratings based ranking. If the service were to support user defined quality criteria then it would be necessary to find a way to store and access users' quality preferences.
3. Third Party Ratings to Guide Resource Selection - Display of ratings from third parties for resources linked to from the current web page, the information displayed may be configurable by user preferences. At the browsing companion end this would require a mechanism for requesting and displaying ratings for resources linked to from the current page. If user preferences were to be taken into account it would be necessary to develop mechanisms for representing, storing and accessing the ratings preferences of a user. At the server end this would require a label bureau capable of providing ratings for a particular resource. Ideally the bureau would be able to contact further bureaux (through the use of centroids) to locate ratings information for a particular resource. The quality vocabularies used by the various third parties may differ depending on their focus (for example, accessibility criteria, subject gateway criteria).
4. Digital Signing of Third Party Ratings - Ratings obtained from a third party (such as a subject gateway) are signed with a digital signature so that users can verify their authenticity. This would require a mechanism for signing ratings as whole and/or individual elements of ratings. At the user end a mechanism to verify digital signatures would be required. The quality vocabulary required to support such a scenario would need to be able to incorporate signed quality statements.