[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Bug 2293: add information_rights to design_product_data_management module
Lothar - I've no access as far as I know to the bugzilla instance you refer to, hence by e-mail, and apology for any delay in replying, since I've been on holiday. 1) It is correct that there is no normative way to populate the model for copyright, since copyright is one instance of information right. It would be useful to create a registry of information rights for their automatic processing, with perhaps the particular case of copyright being treated in an appendix (usage guide) to the module. 2) My guess would be that the absolutely correct way to specify the applicable law would be to create a link (URL?) to the law itself - in many cases this would be most appropriate. The more subtle question is, what subset of information would be most appropriate in an industrial context? - you mention the country that makes the law, but rights could be defined under national law, European law or international convention, or could be defined via agreements through the participating parties, such as contracts, non-disclosure agreements, etc. It seems to me that there is a major modelling job to do to represent this correctly. Or it may just be simpler to cheat, record all the relevant information in a document, and cite it via a documented_element_select, as does PLCS. 3) Agreed it does not assert a particular right against an item. The aim was to manage who could read/modify what in a data sharing context. To do this would need an Information_rights_assertion entity linking Information_rights (as Information_rights_assertion.asserted_right) to an extensible select, and characterized by a person_or_organization and a date_or_date_time. 4) The ability to transfer rights would be modelled by an Information_rights_assertion_relationship, since this would have to assert that the new relationship overrode the old one (which may have be sent in an earlier file and so be recorded in the recipient's database). 5) The extension to qualify an Information_usage_right with a document (such as a licence agreement) is done in PLCS. 6) What does it refer to? - at last someone-else understands the question. The same problem has been around since AP 203 included part_owner (?) against part_definition_formation, and how does it relate to product structure? Unfortunately STEP adopted a "flat" modelling style rather than a hierarchical style, which leaves these questions outside of the scope of the standard. No answer therefore, but probably needs a very broad forum to resolve. As I noted, the aim was to meet the business requirement to track who could do what with information in a shared data environment, particularly the case where two rival suppliers may be part of a design contract, neither of whom should read the other's data. If the requirements extend to recording the assertion of an information right, however, as you correctly noted, what the assertion applies to would be very difficult to define within the STEP file itself. Ignoring that for now, if the module is extended in the way I suggest, there would be no conflict with PLCS. As to the other extensions, the tricky bit is to decide whether the extended characterizations should be built into the module itself, or at some higher level, such as the AP. In the non-STEP work I am doing, I have adopted a style in which NO attributes are applied directly, but rather they are asserted by rules which can be negotiated at run time. If you want to change it, it might also be a good idea to write an new IR schema for information rights, and get a cleaner mapping. Sean Barker 0117 302 8184 > -----Original Message----- > From: Lothar Klein [mailto:lothar.klein@lksoft.com] > Sent: 08 April 2007 16:37 > To: Barker, Sean (UK) > Cc: Tom Thurman > Subject: Bug 2293: add information_rights to > design_product_data_management module > > *** WARNING *** > > This mail has originated outside your organization, either > from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > Sean, > > There is a discussion going on on Sedzilla and I would like > to here your opinion on this. So would you please be so kind > to give us some feedback. You can do it by e-mail or directly > by entering your commnet into bugzilla. > > Thanks in advance > > Lothar > > -------- > Summary: add information_rights to > design_product_data_management module > > http://step.nasa.gov/sparkynet/bugs/show_bug.cgi?id=2293 > > Description: Opened: 2007-04-06 16:09 > > Industrial Original Equipment Manufacturers must share data > in a supply chain, but this 2006 edition does not support > explicit declaration of information rights. > resolution: add information rights module references. > Tom has updated arm express. > > > ------- Additional Comment #1 From Lothar Klein 2007-04-07 > 04:38 ------- > > I agree with the principle requirement, but unfortunately the AM > ISO/TS 10303-1241:2004 Information_rights is not working I > reject to go forward with this until this module is turned > into something useful. And such a change would require > agreement with PLCS and we don't know if the is possible at > all and when. > > Issues against AM Information_rights: > 1) AO Information_right gives as an example "Copyright", but > there is no normative text saying how to decode a particular > copyright. What to choose for attributes id, name, > description and description attributes. Unless these things > are normatively fixed this entity can't be used in computer > sensible data exchange. > > 2) In the description of AO Information_right the term "legal > rights" is mentioned, but unless the country or international > agreement of this right is indicated this entity is > unspecific and so defunct. > > 3) An Information_right such as a copyright if hold on > something. This something is not specified. It is only said > who has right to use something which is different. > > 4) An Information_right on something is owned by some > person/organization at some time and it can be transferred to > someone else. This is not covered at all. > > 5) The kind of an Information_usage_right is only covered by > the name attribute. > This is not sufficient. Typically we have license agreement > which needs to be refereed to. So we need a special kind of > Document for License agreement and refer to this from > Information_usage_right and get rid of the name attribute. > > 6) As with other applied_xxx stuff the scope of the objects > included in the information_usage_right_item is not clear at > all. This select is extended by more than 100 entities, e.g. > Part, Part_version, Part_view_definition. But what does it > mean to include a Part_version? - does it include the > part_view_definitions as well? What does it mean if a > Part_view_definition is included? does it include all the > properties, representations and assembly components as well? > > So my resume is that AM Information_rights is not ready for > any practical use and much more work has to put into it to > make it real working. And it should be reviewed by an > experienced lawyer in international law. > > > ------- Additional Comment #2 From Tom Thurman 2007-04-07 > 11:28 ------- > > The statement that we can't fix the module because PLCS owns > it and we don't believe they will allow us to fix it is not > useful and leads to a 'do nothing' > approach. In fact, PLCS does not own the module. If there are > issues with it we discover during DIS ballot, the DIS ballot > is the time to fix them. > > > My proposal is quite simple and should be considered as > providing a little more classification of properties than > what is already available in Class and Classification_with_attributes. > Your statements about the computer interpretation of scope > and applicability are valid; however the intent was not that > the interpretation would occur in a vacuum. I fully expect > there to be recommended practices, implementation agreements > and contract language spelling out these details for the > foreseeable future. > The detailed interpretation and application of the > Information rights module will only occur once the > information is available in the model. > Recall that today these information rights are asserted at > the file level. > Once we start sharing library data between companies this > will be a problem and we need a first order solution now. > > I will respond to your specific comments by writing a SEDS > against the information rights module. > However, the issues are not significant enough to prevent > including the module as these are not structural changes but > documentation issues. > Re-assign to Giedrius to include the module. > > > ------- Additional Comment #3 From Lothar Klein 2007-04-08 > 05:57 ------- > > I can't agree with this statement: > "However, the issues are not significant enough to prevent > including the module as these are not structural changes but > documentation issues." > > As I tried to proof above the structure of this module is not > suitable at all. > It failed to clearly distinguish between: > - the identification of an information right according to > some national law or international agreement (it can't be a > "right" according to some agreement between persons or > organizations because rights are established only by national laws). > - the information right holder of someone on something > - the information usage right on something for someone > > > ------- Additional Comment #4 From Lothar Klein 2007-04-08 > 06:42 ------- > > One requirement I have on AM Information_rights is to clearly > support the many Open Source and Open Document licenses. See > http://www.opensource.org/licenses/category > for a list of the most prominent ones. And some of these > licenses are not only on software but on any other kind of > "document" which also includes all kinds of product designs. > In particular I would like to highlight here GPLv3 > (http://gplv3.fsf.org/) which uses this definition: > "The "source code" for a work means the preferred form of the > work for making modifications to it. "Object code" means any > non-source form of a work." > > -- > // Lothar Klein, LKSoftWare GmbH > // Steinweg 1, 36093 Kuenzell, Germany > // +49 661 933933-0, Fax: -2 > // url: http://www.lksoft.com > > > ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ********************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]