- From: Bernard Vatant <bernard.vatant@mondeca.com>
- Date: Tue, 27 Sep 2005 18:21:48 +0200
- To: "SW Best Practices" <public-swbp-wg@w3.org>
Following today's telecon, I revisited Requirements and Recommendations for Published Subjects http://www.oasis-open.org/committees/download.php/2897/pubsubj-pt1-1.01-cs.pdf Here they are, with comments wrt the current state of discussion, showing that we are very close to convergence. --------------- Requirement 1 A Published Subject Identifier must be a URI. --------------- So far, so good :)) --------------- Requirement 2 A Published Subject Identifier must resolve to an human-interpretable Published Subject Indicator. --------------- This requirement does not take into account any notion of content negociation, and was thought at the time (more than two years ago) with only the "click-in-browser" situation in mind. So "resolve" is certainly too vague here, but means something like : "A Published Subject Identifier must answer to a http GET request (with an accept field that is not 'application/rdf+xml') by sending back an human-interpretable Published Subject Indicator (with or without redirection)". Or less technically : "A Published Subject Identifier must resolve, if necessary through relevant content negociation, to an human-interpretable Published Subject Indicator." I would gladly see the PubSubj TC, currently quite dormant, revisit this requirement in the light of content negociation. --------------- Requirement 3 A Published Subject Indicator must explicitly state the unique URI that is to be used as its Published Subject Identifier. NOTE: PSIDs should be used exactly as published since processors cannot be expected to perform URI normalization. --------------- That means the human-interpretable stuff includes explicitly the normative URI of the identified resource. This is what is done currently by SKOS. For example the subject indicator at http://www.w3.org/TR/swbp-skos-core-spec/#prefLabel says explicitly it indicates the resource defined by http://www.w3.org/2004/02/skos/core#prefLabel. So if the latter redirects to the former, as Alistair suggests, it will be completely compliant with this requirement. --------------- Recommendation 1 A Published Subject Indicator should provide human-readable metadata about itself. --------------- We stumble on the impossibility to define what those metadata might/should/must be. So anything can go there. --------------- Recommendation 2 A Published Subject Indicator may provide machine-processable metadata about itself. NOTE: Machine-processable metadata is recommended so that applications can help users discover and evaluate the suitability of PSIs. Human-readable as well as machine-processable metadata can be included in the Subject Indicator itself (e.g., as RDF metadata) or in a separate information resource referenced from the Subject Indicator (e.g., as XTM metadata). --------------- There again the way the machine-processable metadata (read : formal schema) are linked to/from the human-readable stuff is left open. If content negociation is available, it's OK, if RDF is embedded in the human-readable page; it's OK too. --------------- Recommendation 3 Metadata defined in Recommendations 1 and 2 should be consistent, but need not necessarily be equivalent. NOTE: Consistency between human-readable and machine-processable metadata guarantees consistent "interpretation" by applications and humans. This can be achieved, for example, by human-readable metadata being a rendition of machine-processable metadata. This issue will be addressed by Deliverable 2. --------------- This recommendation actually does not say much, since the notion of "consistency" or "equivalence" between human-readable metadata and machine-processable metadata is really ill-defined, to say the least, in this document like anywhere else. Beyond the issue of workflow synchronisation, there is the sheer fact that defining consistency or equivalence between a formal and a non-formal representation is by itself a challenge ... But it opens the door to having more or less information for humans than for machines. So, for example, the DCMI case where there is a discrepancy between the two descriptions is not in conflict with this recommendation. In conclusion, it seems the consensus we are about to reach for the VM note is not conflicting the above requirements and recommendations. The other way round, it provides an occasion for refining them to take into account the content negociation situation. I forward this message to the PubSubj TC list, with its context, and will provide feedback to this group if any reaction comes from there. ---------------------------------- Bernard Vatant Mondeca Knowledge Engineering bernard.vatant@mondeca.com (+33) 0871 488 459 http://www.mondeca.com http://universimmedia.blogspot.com ----------------------------------
Received on Tuesday, 27 September 2005 16:22:13 UTC