OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-metadata] Fwd: [ext-CC] Re: CC extension


Bruce,

Bruce D'Arcus wrote:

> From a conversation about a new effort to add a Creative Commons 
> extension to OOo; I just mentioned our work to them, and reply below ...
>
> Begin forwarded message:
>
>> Date: October 25, 2006 8:38:01 AM EDT
>> To: creativecommons@extensions.openoffice.org
>> Subject: Re: [ext-CC] Re: CC extension
>>
>> On Oct 25, 2006, at 3:49 AM, Malte Timmermann wrote:
>>
>>> So IMHO:
>>> - If the license is only a link in the document, pointing to cc.org, 
>>> and
>>> you just want to remember somewhere that a license was added, use 
>>> meta data.
>>> - If you want to store a local copy of the license, so people can 
>>> see it
>>> w/o being online, store it in some license.xml stream in META-INF, next
>>> to the signatures.
>>
>>
>> I think this is a false choice (metadata vs. local copy). The 
>> metadata system would support both options. So you add this to your 
>> metadata file:
>>
>> <cc:license 
>> rdf:resource="http://creativecommons.org/licenses/by-sa/2.0/"/>
>>
>> If you want, then include the RDF files as well in the package (per 
>> above):
>>
>>    <License rdf:about="http://creativecommons.org/licenses/by-sa/2.0/";>
>>      <permits rdf:resource="http://web.resource.org/cc/Reproduction"/>
>>      <permits rdf:resource="http://web.resource.org/cc/Distribution"/>
>>      <requires rdf:resource="http://web.resource.org/cc/Notice"/>
>>      <requires rdf:resource="http://web.resource.org/cc/Attribution"/>
>>      <permits 
>> rdf:resource="http://web.resource.org/cc/DerivativeWorks"/>
>>      <requires rdf:resource="http://web.resource.org/cc/ShareAlike"/>
>>    </License>
>>
>> My point is there isn't really a need since the file is available on 
>> the web.
>>
Sigh.

Sorry, the "file is available on the web" is only a sufficient answer if 
and only if:

1. The file is always going to be available.

2. The file is never going to change.

3. The file can be verified to not have changed.

I don't include you (Bruce) in this observation but to think otherwise 
is simply goofy optimism that is inconsistent with history both prior to 
and since the web.

How do I verify the reference to the book of the Wars of Yahweh in 
Numbers 21:14? My copy seems to be missing.

Or, if you want something more recent,  what of ODA (Office Document 
Architecture)? An ISO standard from the 1980's that was simply discarded 
when it wasn't renewed. (Fear not! I happen to have obtained an 
electronic copy that has been backed up to both electronic and print 
media. I need to get around to getting permission to deposit a copy with 
a library archive as ISO still has the copyright on the text.)

Or, what of current 404's?

Sure, a file possibly existed at all those locations, maybe, but we 
don't know now what content they may have had on any particular date, if 
any.

Note that is it *insufficient* to say that is a "social problem" or 
similar efforts to pretend it's not a problem. Simply washing one's 
hands of a problem, like the identity problem is simply to stick one's 
head in the sand (sanitized in case some child stumbles across this 
post) and to pretend the problem isn't real.

I understand that for some purposes we may choose to treat URI's as 
though they are meaningful. But, that should be with a knowing 
assumption of the risk that they in fact may not be meaningful at all, 
now or when we most need them to be meaningful and to conduct ourselves 
accordingly.

For my part, I would always include a license as what you call a "local 
copy." And would rest better if the file where it was included could be 
digitally signed. No absolute guarantee but safer than simply assuming 
some URI would be meaningful during the date of death plus 75 years that 
is the term of copyright in some places, for example.

It is a real problem and not one we can simply wish away.

Apologies for the outburst. I have been working on a very, very long 
draft of a standard with short, almost cryptic element names and that 
has made me cranky. (Or more so than usual.)  :-) I would write a script 
to replace the element names with meaningful names but that would 
probably bulk it up by several thousand pages. :-( I don't want to kill 
any more forests than necessary to have a hard copy to work from. An old 
academic prejudice but I don't think you can adequately proofread from 
electronic copy any more than you can cook from a recipe book. It can be 
done but the results in either case doesn't taste quite the same. I 
know, I know, newspaper production companies, news magazines, etc., do 
it all the time. Simply proves my point. ;-)

Hope you are having a great day!

Patrick



 

-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work! 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]