[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Groups - IPC WD-05 uploaded
OK, I can go along with this set of attributes. As we discussed at the last TC telecon, maybe use “agreement-id” instead of “agreement-designator”. Please make sure to specify the meaning of each attribute as precisely as possible. I tried to do this in the marked-up document I posted last week. As for adopting foreign vocabulary terms (e.g. Dublin core), I am leaning more against that unless the foreign term is defined in its native context to have a value range compatible with XACML datatypes. That would exclude dc:creator, which has a range of dc:Agent. On the other hand, dc:created (date of creation) is defined with a range of rdfs:Literal. Instances of xs:date or xs:dateTime are literal values, so it would be OK to define dc:created as a XACML attribute with datatype of xs:date or xs:dateTime. (See http://dublincore.org/documents/2010/10/11/dcmi-terms/) Regards, --Paul From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Tolbert, John W Paul, I am okay with most of the glossary additions/changes and changes to the descriptive text in the attributes. I would prefer to keep “Agreement-Designator” instead of “IP-Agreement”, because language granting rights to IP resources often occurs outside an agreement which is solely about IP. This is another reason why we need a “third-person” way of representing legal agreements in XACML, as you postulated earlier. Responding to input from our last meeting, I have started WD-06 with a restructuring of the resource attributes. I have also included “creator” and “rights” from Dublin Core, and referenced them as such. I have removed “IP-Type” and “IP-Data”, and substituted Boolean data types for each of the top-level types, and string/date data types for the products of the former IP-Type x IP-Data matrix. 2.1 Resource Attributes 2.1.1 Copyright (Boolean) 2.1.2 Copyright-Creator (String) 2.1.3 Copyright-Registration (String) 2.1.4 Patent (Boolean) 2.1.5 Patent-Registration (String) 2.1.6 Proprietary (Boolean) 2.1.7 Public-Domain (Boolean) 2.1.8 Trademark (Boolean) 2.1.9 IP-Owner (String) 2.1.10 IP-Designee (String) 2.1.11 Agreement-Type (String) 2.1.12 Agreement-Designator (String) 2.1.13 Rights (String) 2.1.14 Effective-Date (Date) 2.1.15 Expiration-Date (Date) 2.2 Subject Attributes 2.2.1 Organizational-Affiliation (String) 2.2.2 Affiliation-Type (String) 2.2.3 Agreement-Designator (String) I am interested in additional feedback on the idea of having separate effective/expiration date attributes for copyright, patent, and trademark registrations. I believe these changes should aid understanding and simplify policy authoring. I also believe that, while the structure of the profile has changed in the various iterations, the core concepts expressed have remained essentially the same, and that we are reasonably close to finalizing this profile for now. I do not think we are standardizing too much. The attribute list reflects a fairly broad and not industry/ country specific interpretation of how access to intellectual property resources can be governed. Not every IP authorization decision will use every attribute listed. Furthermore, I know that organizations will need to define additional attributes for their own internal purposes. This profile establishes a baseline that can promote interoperability and can be used as a framework to advance the common framework for IP authorization decisions. Thanks, John From: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com] I’m not through making comments, but I wanted to get this out for discussion. I think we still have a ways to go on this. My primary concern is not to standardize too much without sufficient motivation or evidence. Regards, --Paul From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of John Tolbert Submitter's message
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]