Re: 'right' vs 'permission'; was: RE: [rights-requirements] Parallelor Complimentary System

[Patrick Durusau <pdurusau@emory.edu>]

Thomas,

DeMartini, Thomas wrote:

>>What did you think about the idea that the outcome of right vs. 
>>permissions could be the same but differ in terms of the process by 
>>which the outcome would be reached?
>>
> 
>In order to answer this question, let me first add some context from your original e-mail:
>
>"If pressed I would hazard that at least one way to distinguish rights
>and permissions is: Do I have to ask before I can do some particular
>action? If the answer is no, then we are talking about a right. If the
>answer is yes, then we are talking about a permission."
>
>The thing to realize is that if the answer is no (what you call rights) then we don't have any communication.  And, if we don't have any communication, then we don't need a language.  And, if we don't need a language, then it is not in the scope of a language technical committee.
>
Sorry, you missed me with the "we don't have any communication...." point.

What sort of communication are you envisioning is required?

>
>On the other hand, if the answer is yes (what you call permissions), then we have communication.  And, thus, need a language.
>
>Does this make sense?  We have to keep in mind always that we are only defining a language, and not a DRM system.
>
Not really. I think my point would be that the "language" in your sense 
is presupposing a system of some sort (DRM or otherwise) even though it 
wants to say it is not a "system."

Certainly there are models and languages that operate without 
point-to-point communication, such as the current legal system, which 
does not require me to have actual notice of laws but only constructive 
notice, i.e., published in some official publication that I never read. 
(Please don't follow this analogy down a rabbit hole, I realize that no 
computer language or system could implement constructive notice but I 
have to use examples to explain the point.)

If your language presupposes point-to-point communication, for me the 
question becomes how do the many requirements that have been filed fit 
into the presumed point-to-point system? (I do not concede that "fair 
use" could not be modeled in a point-to-point system, but do want to get 
this system presumption of the language made clear.)

Language issues, both within and without computer systems, are not 
nearly as transparent as some of the TC documentation would lead one to 
believe. I just got an 4 century BCE Sanskrit grammar in the mail 
yesterday for use in a paper I am doing on the development of BNF 
syntax. Language issues are not simple and any system designed with that 
presumption is likely to have serious holes and problems. That is not to 
say we must fix every possible hole or patch every blemish but starting 
with the presumption that all is complete and clear, seems equally 
unproductive.

BTW, on the scope of the language technical committee issue, defining 
what the language does not address (or cannot address) seems to me to be 
as important as defining what it does address. Would be a serious error 
(in my opinion) to release a language that claims to address everything 
when in fact it addresses a known subset of issues. Perl does string 
matching very well but I don't think anyone would recommend it for FFT 
operations on very large data sets. (Please Perl fans, I like Perl, use 
it, but for data sets processed on large array processing systems there 
are other options. It is a question of the right tool for the job.)

I think the language technical committee would be the place most likely 
to know the limitations of a language and hence the appropriate venue 
for those discussions.

Well, got to run. Have medical appointments (just checkups) that will 
consume most of the day. Will take the core with me so perhaps I can 
have some examples to post next week.

Have a great weekend!

Patrick


>
>Thanks,
>
>Thomas.
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu