tor 2007-11-01 klockan 14:03 +0000 skrev Sarah Currier:
> Hi Pete,
> 
> Thanks very much for yet again giving so much time to answer a
> question so thoroughly!  My comments that follow are in no way
> directed at you :-) 
> 
> I can scarcely believe that it took the Scholarly Works Application
> Profile, in 2006, to define a "hasTranslation" property- and even now
> there's no isTranslationOf to reciprocate.  In all these years has
> noone needed a hasTranslation property, if hasVersion isn't
> appropriate?  Isn't it an obvious Relation Type?  Why wasn't it
> included originally?  Was there an isBasedOn property and what
> happened to it?  It's certainly usable in other cases for learning
> objects- for a re-purposed learning object based on another learning
> object, something that most people would not consider to be a new
> version of the original- generally it'll be a new author's creation.
> 
> OK, I'll stop spluttering now; I've probably ended up making some busy
> person who's been working on Dublin Core since the beginning feel the
> need to write a defence of earlier decisions (although I have to say I
> always find those interesting).  I have a feeling we're going to have
> to end up going against Pete's advice for purely practical reasons-
> but it's food for thought and I'll think some more.

Another way of looking at the issue is the traditional tension between
defining a very specific property that caters to your needs, and reusing
a very generic one to support interoperability. 

My 0.02 kronor (= 2 öre) here is that if you need "hasTranslation",
either define it yourselves or reuse the ePrints one. Don't use the
generic properties when you have a very well-defined usage that benefits
from being distinguished from the other uses of that property.

I think the ePrints community might be convinced that they need to
define an inverse property. 

And of course, they need to be declared subProperties of the more
generic properties. The above discussion would then be about that part
(which super-property would it be?), rather than about which property to
use in instance metadata. 

/Mikael

> 
> Cheers
> Sarah
> 
> Pete Johnston wrote: 
> > Hi Sarah,
> >  
> >   
> > > Been doing a bit of research in the list archives to answer a 
> > > question for myself and have ended up more confused.  Any 
> > > help from old hands or current implementers appreciated.
> > > 
> > > Looking at how to indicate that a resource is a translation 
> > > of another resource, I assumed that isVersionOf / hasVersion 
> > > were the appropriate refinements on Relation.
> > > 
> > > The current usage guidelines don't appear to be very much in 
> > > agreement with this: "The described resource is a version, 
> > > edition, or adaptation of the referenced resource. Changes in 
> > > version imply substantive changes in content rather than 
> > > differences in format."  Is a translation a "substantive 
> > > change in content"?
> > > 
> > > I found some very old emails in the list archive that 
> > > indicated that isBasedOn / isBasisFor were once supposed to 
> > > be used for translations.  
> > > I can't tell if this was ever actually included in 
> > > recommended DC, or if it was just an early discussion.
> > > 
> > > The complexity is increased by the fact that our system is 
> > > structured on IEEE LOM metadata, but we offer crosswalks to 
> > > Dublin Core- but the LOM
> > > *does* include the terms isBasedOn / isBasisFor as well as 
> > > the Version ones.  Not sure if the LOM once upon a time based 
> > > its vocabulary on the then-DC vocabulary, or if something 
> > > else happened, but I guess its irrelevant now  :-)
> > > 
> > > Is it the case that isVersionOf / hasVersion are now used to 
> > > indicate a translation relationship?
> > >     
> > 
> > I think the answer to that specific question is "no". The
> > dcterms:isVersionOf and dcterms:hasVersion properties do not "indicate"
> > - specifically - a translation relationship. 
> > 
> > As you suggest, given that DCMI definition which you quote above, there
> > _may_ be an argument that a translation relationship is indeed one of
> > the types of relationship that "falls within" the broader pair of types
> > of relationship represented by the isVersionOf/hasVersion properties
> > (more below). But, even if that is the case, if you want to indicate
> > _specifically_ a hasTranslation/isTranslationOf relationship (rather
> > than that broader relationship types) then you need a different pair of
> > properties.
> > 
> > On the question of whether a translation relationship is indeed one of
> > the types of relationship that "falls within" the broader type of
> > relationship represented by the isVersionOf/hasVersion properties, it
> > may be helpful to look at FRBR (though, no, the
> > dcterms:hasVersion/isVersonOf properties weren't, as far as I know,
> > based on FRBR). 
> > 
> > http://www.ifla.org/VII/s13/frbr/frbr.pdf
> > 
> > >From 5.3.2 Expression-to-Expression Relationships, page 71:
> > 
> > ===
> > In these types of relationships, one expression is seen to be a
> > modification of the other. The modification may be a literal
> > translation, in which the intent is to render the intellectual content
> > of the previous expression as accurately as possible (note that free
> > translations are treated in the model as new works); a revision, in
> > which the intent is to alter or update the content of the prior
> > expression, but without changing the content so much that it becomes a
> > new work; an abridgement, in which some content of the previous
> > expression is removed, but the result does not alter the content to the
> > extent that it becomes a new work; or an arrangement of a musical
> > composition.
> > ===
> > 
> > Given that FRBR regards the intent of "translation" as "to render the
> > intellectual content of the previous expression as accurately as
> > possible" and the DCMI descriptions of dcterms:hasVersion and
> > dcterms:isVersionOf explicitly require "substantive changes in content",
> > then I'd suggest that a translation relationship does _not_ fall within
> > those broader relationship types represented by the dcterms:hasVersion
> > and dcterms:isVersionOf properties, and therefore a different pair of
> > properties is required for the hasTranslation/isTranslationOf cases (and
> > these new properties would not be subproperties of the
> > dcterms:hasVersion and dcterms:isVersionOf properties).
> > 
> > That's my interpretation, anyway. But as you say, it really hinges on
> > how you interpret the word "content" in the two cases, and other people
> > may well disagree with my interpretation here.
> > 
> > FWIW, in the context of the work on the ePrints DC Application Profile,
> > the project defined a distinct property
> > 
> > http://purl.org/eprint/terms/hasTranslation
> > 
> > specifically for this purpose. AFAIK, the inverse (isTranslationOf, or
> > something like that) wasn't defined.
> > 
> > There are also other RDF vocabularies for FRBR which provide similar
> > properties. See e.g.
> > 
> > http://purl.org/vocab/frbr/core#
> > 
> > which defines
> > 
> > http://purl.org/vocab/frbr/core#translationOf
> > http://purl.org/vocab/frbr/core#translation
> > 
> > But N.B. these properties have a Domain/Range of frbr:Expression i.e.
> > their use in a "statement" implies that both the "described resource"
> > and the "value" (in DCAM terms) are both frbr:Expreessions, which may or
> > may not meet your requirements! ;-)
> > 
> > Pete
> > ---
> > Pete Johnston
> > Technical Researcher, Eduserv Foundation
> > Web: http://www.eduserv.org.uk/foundation/people/petejohnston/
> > Weblog: http://efoundations.typepad.com/efoundations/
> > Email: [log in to unmask] 
> > Tel: +44 (0)1225 474323
> >   
> 
> -- 
> Sarah Currier
> Product Manager, Intrallect Ltd.
> http://www.intrallect.com
> 
> 2nd Floor, Regent House
> Blackness Road
> Linlithgow
> EH49 7HU
> United Kingdom
> 
> Tel: +44 870 234 3933    Mob: +44 (0)7980855801
> E-mail: [log in to unmask] 
> --
-- 
<[log in to unmask]>

Plus ça change, plus c'est la même chose