TR: [VM] Convergence of VM note with OASIS Published Subjects Recommendations

["Bernard Vatant" <bernard.vatant@mondeca.com>]

Dear all

Please find below a message I just posted to the W3C SWBPP Vocabulary Management Task
Force.
http://www.w3.org/2001/sw/BestPractices/VM/
One current task is to compare and try to align practices of FOAF, SKOS and DCMI (all
involved in this TF)
See e.g http://lists.w3.org/Archives/Public/public-swbp-wg/2005Sep/0111.html

In this message I've tried to see how the current consensus of this TF is consistent with
our TC recommendations.
Seems that there is a real convergence, and that maybe we should revisit Requirement 2 to
take into account the notion of content negociation, enabling the same URI to provide
computer stuff to computers, and human stuff to humans.

Feedback welcome.

Bernard


-----Message d'origine-----
De : Bernard Vatant [mailto:bernard.vatant@mondeca.com]
Envoyé : mardi 27 septembre 2005 18:22
À : SW Best Practices
Objet : [VM] Convergence of VM note with OASIS Published Subjects
Recommendations


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
----------------------------------