Pete,

Thanks for clearing that up. I thought I must have missed something 
there. Perhaps this is why I couldn't get it to work with the Scribd 
example, whereas the other two worked fine with just the URI. (Dunno if 
it fails where the markup is wrong...?)
> This is more than simply the URI of the Flash object: it also provides
> other markup which reflects how YouTube wants the object to be rendered
> on my page. As far as I know there is no URI which identifies
> specifically that fragment of markup (though I could be wrong on that
> point).
>   
I'm pretty sure you're right, in that case.
> So I was posing the question of whether this info is useful to consumers
> of SWAP metadata - so that, e.g., an aggregator can embed the video in
> the pages it exposes in the YouTube-approved style - yes, I imagine, one
> could reconstruct one's own version of the player given only the URI of
> the Flash object and some metadata about image size etc, but that would
> seem to me to contravene the ToS I cited. 
>   
I'm still not sure why this would be actually illegal, since there is no 
copyright breach and the means to do it has been provided by the website 
operator in the first place. Of course they could withdraw your 
acccount, which would be a pain, I guess. However, it's likely that so 
few of their users would do this that I personally doubt whether such 
websites are going to take action on the basis of freely available 
content. They would most likely simply block the ability to do this, as 
I was under the impression Scribd might be doing.
> If it is useful, then I don't think SWAP's current spec for describing a
> Copy/Item provides a means of recording this information - which is
> understandable as I don't think it was considered as a functional
> requirement at the time. There may well be additional complications in
> doing this that I haven't thought of! But it does seem like a useful
> piece of additional metadata that could be supported in a Copy/Item
> description in a fairly simple way
>
> Copy:C ex:embedCode "<object>....</object>" .
>
> (or some existing property if there is one out there that does the job)
>   
Thus far we haven't demonstrated that SWAP in its present form is the 
best tool to do the job it was designed for, in the sense that there are 
currently no implementations or tools to provide them. While I don't 
reject your proposed use case by any means, it must be said that SWAP 
and the other DCAPs face far more pressing issues. The fact that these 
URIs and/or HTML embed codes are not necessarily persistent means that 
they aren't maybe the best things to have in one's metadata as pointers 
to resources.

 From the metadata perspective, HTML is just a free text record. 
Suggested quick-and-dirty repository manager solution: do what everyone 
else does and put it in dc:description as the metadata field of last 
resort. (We need to remember that the more custom fields we create, the 
more complications we will introduce into SWAP without any assurance 
that the community actually needs or wants them.) Otherwise simply 
archive the resources elsewhere, provided that you retain copyright over 
the content under the agreement that you sign with any given service (?)

While this is an interesting issue and perhaps one to re-visit 
(including the possibility of storing *any* HTML that might be relevant 
to the resource in question), it does seem to me that it isn't the 
number one priority for SWAP and the other DCAPs right now.


Talat

-- 
Dr Talat Chaudhri
------------------------------------------------------------
Research Officer
UKOLN, University of Bath, Bath BA2 7AY, Great Britain
Telephone: +44 (0)1225 385105    Fax: +44 (0)1225 386838
E-mail: [log in to unmask]   Skype: talat.chaudhri
Web: http://www.ukoln.ac.uk/ukoln/staff/t.chaudhri/
------------------------------------------------------------