Dear all,
here the pointer to our preliminary draft: http://
At the moment we worked out the "informal" description of the rules.
Unfortunately we did not address all the issues but it is very
important for the TF to have your opinion about the approach taken
and the structure of the document.
We are still adding contents, so it's likely we'll have few more
elements to discuss about during the f2f.
Many thanks for your help.
Regards,
Valentina
Valentina Presutti
Phd Student of Computer Science
Department of Computer Science
University of Bologna
Mura anteo Zamboni 7
Ph. +39 (0)51 20 94871
Fax. +39 (0)51 20 94510
home page: http://www.cs.unibo.it/~presutti

Dear Pat,

many thanks for your comments.
I'll fix the document at my best considering them.

If I might make a suggestion, it is usually less work in the long
run to work out the formal mappings first, and then make sure that
the informal account follows the mathematics. Informal rules made
without paying attention to the underlying foundations are almost
never correct.
--
You're probably right.
intention is to go through the formal specification after the f2f
meeting as we have to decide which formalism to use for this aim.

A first quick look prompts the following immediate comment.

The translation from RDFS to TM is defined in such a way that it
depends on information which may not be available, in particular
whether a resource is a member of the class
rdftm:InformationResource. What is the intended translation
technique to be used when membership in this class is unknown (as
it will often be, presumably)?

Thank you for pointing out this.
The approach for RDF/TM interoperability is twofold.
one hand we have unguided translation, on the other hand we have
guided translation.
This preliminary draft is about "guided" translation. In fact it is
based on the rdftm: vocabulary which is used for explicitly express
how the translation has to be performed.
We chose first to deal with guided translation.
This is why we assume to have such information available to those rules.
Probably, this is not clear by the current version, I'll try to do it
soon.

A related point, the document gives as an RDFTM 'rule',

"If the resource is not an instance of rdftm:InformationResource,
the resource becomes a subject locator"

How is it possible to determine in RDFS that a resource is NT an
instance of a class? Such information can be expressed in WL, but
not in RDFS. It is not valid to infer non-membership in a class
from a failure to prove membership in that class. The translation
rule as stated seems therefore to be inapplicable to RDFS-to-TM
translation, or ill-defined, or possibly both.

I agree with you. Do you think it might be better to say:
"If the resource is not explicitly an instance of
rdftm:InformationResource" pointing out that we are referring to
the guidance.
To declare that a resource is an instance of
rdftm:InformationResource is a way to say how to handle the URI of
that resource in Topic Maps. Not to do it give a the same information
leading to a different result.

I will send other comments later when I have had time to study the
document more carefully, but these points seem central and require
immediate attention.

Thank you very much for your help.

Valentina

Valentina Presutti

Phd Student of Computer Science
Department of Computer Science
University of Bologna
Mura anteo Zamboni 7
Ph. +39 (0)51 20 94871
Fax. +39 (0)51 20 94510
home page: http://www.cs.unibo.it/~presutti