TOC 
Network Working GroupI. Maturana
Internet-DraftI. Robredo
Expires: December 30, 2004in3activa
 July 2004

Scope Modifiers in Intellectual Property Declarations

draft-maturana-ipscope-02.txt

Status of this Memo

This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on December 30, 2004.

Copyright Notice

Copyright (C) The Internet Society (2004).

Abstract

The purpose of this RFC is to focus discussion on intellectual property problems in the Internet.

This document introduces and defines scope modifiers to be used in intellectual property declarations. These modifiers abstract the ownership behavior of resources available in interoperable environments, such as the Internet.



Table of Contents

1.  Introduction
    1.1  Intended audience
    1.2  Definitions
    1.3  Requirement notation
2.  Semantics of interoperability
    2.1  An analogy: the logic of classes
    2.2  Categories of operations
    2.3  Reciprocity and equivalence
3.  Definition of scope modifiers
    3.1  PRIVATE modifier
    3.2  PROTECTED modifier
    3.3  INTERNET modifier
    3.4  PUBLIC modifier
    3.5  Scope inheritance
4.  Syntax of ownership declarations
    4.1  Formal declaration
    4.2  Property line
    4.3  Attribution line
    4.4  License line
    4.5  Long names and short names of modifiers
5.  Scope modifiers implementation
    5.1  Handwritten implementation: the default modifier
    5.2  HTML implementation: the SCOPE tag
    5.3  Dublin Core implementation
    5.4  Using licenses
6.  Security Considerations
7.  References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1. Introduction

This document defines four scope modifiers to be used in intellectual property declarations of resources available in interoperable environments, such as Internet. They help to abstract the ownership behavior of these resources.

We proceed in three steps. We characterize the semantics of the operations applicable on resources, based on the pair (URI, ownership). Then we determine the modifiers that control the interoperability of resources. Finally we describe the general syntax of the ownership declarations that use these modifiers. An fourth chapter will introduce various implementations of the described syntax.

Four modifiers are defined. The PUBLIC, PROTECTED and PRIVATE modifiers are transpositions of the class programming equivalents. A fourth modifier -- the INTERNET modifier -- operates like an all-country exclusion: it allows the transformation, but does not allow the reproduction, of a private resource exhibited in interoperable environments, such as Internet.

As an example, the following declaration illustrates a typical usage of the PUBLIC and PRIVATE modifiers. This declaration asserts that OwnerB's private resource (the client resource) is a derivative version of OwnerA's public resource (the server resource).

 
    Private(C) 2004, OwnerB (http://www.client.com)
    & Public(C) 2002-2004, OwnerA (http://www.server.com)
    All rights reserved.
 

1.1 Intended audience

No special knowledge is expected from readers. However, some concepts have a background and rely on a vocabulary that is more familiar to specialized readers:

1.2 Definitions

INTELLECTUAL PROPERTY BASED OBJECT (IP OBJECT) is an instance of a work, as defined by Berne Convention (Art. 2), and the laws of the countries of the Berne Union [BERNE]World Intellectual Property Organization, WIPO., Berne Convention for the Protection of Literary and Artistic Works, Paris Act of July 24, 1971, as amended on September 28, 1979..

RESOURCE is an IP Object defined unambiguously in an interoperable environment by two properties: its URI and an ownership declaration. More strictly, a resource is an interface defined by the pair (URI, ownership) of an IP object made available in an interoperable universe

OWNERSHIP is a resource property, defined by the Berne Convention (Art. 5), and the laws of the countries of the Berne Union [BERNE]World Intellectual Property Organization, WIPO., Berne Convention for the Protection of Literary and Artistic Works, Paris Act of July 24, 1971, as amended on September 28, 1979..

URI is a resource property, the Universal Resource Identifier of an IP object, defined in [RFC2396]Berners-Lee, T., Fielding, R., Irvine, U. and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, August 1998..

SCOPE (OF OWNERSHIP), as used in this document, determines the resource behavior in regard of specific operations: exhibition (instantiation), execution (performance), reproduction (copy) and transformation (derivation). Brackets only denote synonyms for operations defined in this document.

SCOPE MODIFIER, is a conventional token attached to an ownership declaration, used to alter the behavior of the resource in an interoperable environment.
The aim of this document is to define and to describe such scope modifiers.

SERVER and CLIENT RESOURCES. A server resource refers to the original resource, which has been reproduced or transformed, to create a client resource.
A client resource is the resulting reproduction or transformation of a server resource.
A version is also a client resource, which designates specifically the result of the transformation of the server resource.

INTEROPERABILITY is defined following the IEEE Standard Computer Dictionary: "the ability of two or more systems or components ("resources") to exchange information and to use the information that has been exchanged" [IEEE 90]Institute of Electrical and Electronics Engineers, IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY, 1990..

INTERNET, is an interoperable environment of resources.
In this document, INTERNET is also the conventional name of a scope modifier.

1.3 Requirement notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, March 1997..



 TOC 

2. Semantics of interoperability

This first chapter will analyze the semantic of the operations applicable on resources. Next chapter defines the scope modifiers that alter the behavior of resources; and the last chapter describes the general syntax of the ownership declarations.

2.1 An analogy: the logic of classes

As a starting point, we present an analogy between Resources declarations and Class declarations used in class programming languages. This analogy is not required to fully understand this document.

Given the "(c) year, author" expression, the legal mention to the Country is implicit. Indeed, we could write:

        "France (c) 2004, I.Robredo"

In our example, "Country" is a virtual base class, from which we derive a special rightsholder class: the class "I.Robredo". Each instance of this Rightsholder class is a concrete IP Object, identified unambiguously by an URI. For example, the URI of a manuscript or a song is the title, the author's name and the date.

The declaration above may be read as follow:

 
     "France (c) 2004, I.Robredo"
     
     Is an ownership declaration of an IP object, where:
     
        France      is the name of the virtual, country base class.
                    Optional. By default, the author's country.

        I.Robredo   is the name of the rightsholder class, 
                    derived from the country class 
                    (usually the Author's name, but can be any 
                    entity).

        ... 2004    is an instance of the I.Robredo class. The 
                    IP object itself is defined by the 2004 version 
                    (along with the title, the author's name, ...). 
 
     

An ownership declaration can be used when the rightsholder wants to make available an IP Object in an interoperable environment, under specific conditions of ownership. This object is called a resource. Two properties will determine the resource behavior in the interoperable environment: its URI and the ownership declaration.

Before being available, the resource is unknown and the ownership declaration is not even required. This declaration is really required to allow some interoperations on the resource. In other words, the ownership declaration is used to determine or to alter the interoperability of the resource.

In Class programming languages, special modifiers attached to Class declarations are used to determine the results of operations on the classes and on the object instances. In other words, these modifiers can define the semantics of the relations between classes or between objects. This document shows that similar conventions can be applied to the resources exhibited in interoperable environments, such as Internet.

2.2 Categories of operations

A resource is defined by a couple of properties: its URI and its ownership declaration.

Some relations may be identified between these properties:

All these relations are contained in the answers to the following two questions. For any operation:

Four operations are defined as follows (alias names are parenthesized):

 
  EXHIBITION  (Instantiation) The Owner instantiates an IP Object 
              by defining its URI and ownership properties. 
              Exhibition of the resource is always accomplished by 
              the rightsholder (for example: the author).

  EXECUTION   (Performance) There is no URI creation. A volatile
              instance of the IP Object is performed. 
              Whether the performer is the rightsholder or another 
              different person, the ownership of this volatile 
              resource remains the same, and belongs to the original 
              rightsholder. 

  REPRODUCTION (Copy) A new, persistent URI is created, and the 
              resource exhibited under this new URI is called a 
              "client resource".
              Whether the underlying object under each URI is the 
              same object or a duplicate object, the ownership of
              both server and client resources remains the same, and 
              belongs to the original rightsholder.

  TRANSFORMATION (Derivation) A new, persistent client resource 
              is created, with separate properties (URI, ownership). 
              This client resource is called a "version" of the 
              original server resource.
              Even whether the rightsholder of both server and 
              client resources is the same person, the ownership 
              attached to the version resource is different from 
              the ownership of the original resource.
              The ownership declaration on the version is asserted 
              by the exhibitor of the resource.
 

The following table resumes the above relations between URI and ownership:

 
     Operation       | Question 1:     Question 2: 
                     | Is there a 2nd  In case of URI creation, is 
                     | URI creation?   there a separate ownership?
     ----------------|--------------------------------------------
     EXHIBITION      |  No              -
     EXECUTION       |  No              - 
                     |
     REPRODUCTION    |  Yes             No 
     TRANSFORMATION  |  Yes             Yes
     ----------------|--------------------------------------------
 

2.3 Reciprocity and equivalence

This section is not required to fully understand this document, and it refers explicitly to the 5 first articles of the Berne Convention. [BERNE]World Intellectual Property Organization, WIPO., Berne Convention for the Protection of Literary and Artistic Works, Paris Act of July 24, 1971, as amended on September 28, 1979..

The exhibition and execution operations require some explanations.

Otherness is the key concept to differentiate exhibition and execution: the person who executes a resource is not required to be the same person who exhibits it. The exhibitor and the performer of the work can be different persons. For example, given a computer software, we say that only the rightsholder can exhibit the source code, while any (authorized) person can execute the object code.

Otherness is the basis of two complementary principles: the reciprocity in protection given by countries (Berne-A3 and A5) and the equivalence in ownership of transformed resources (Berne A2.3). Both principles are governed by an explicit non-damaging restriction: client ownership cannot make prejudice to server ownership.

We say that this non-damaging rule governs the "inheritance" of resource behaviors.

Ideally, allowing the transformation of a resource does not imply that the derivative resource can be transformed as well. There is a separate ownership between both server and client resources, in case of transformation. However, the non-damaging rule still works here, either explicitly, or implicitly:

The non-damaging rule can enforce the inheritance. The same rule can also alter the default reciprocity and equivalence behaviors. In this case, the way to alter the default inheritance mechanism is using scope modifiers.



 TOC 

3. Definition of scope modifiers

In the previous chapter, we analyzed the semantics of inter-operations on resources defined by the pair (URI, ownership). In this chapter, we define the modifiers that are used to alter the resource behaviors. The general syntax of the ownership declarations will be described in the next chapter.

There is a formal relationship between the URI property and the EXECUTION or REPRODUCTION operations. A second URI is always attached to all reproductions of the resource. In other words, the difference between a simple execution and a true reproduction raises when a new URI is defined for the copied resource.

Conversely, there is a semantic relationship between the ownership property and the EXHIBITION and TRANSFORMATION operations. An exhibited resource is always managed by its rightsholder. However, a true transformation implies a second user, which in turn, has a complete ownership on the version produced.

The following summarizes REPRODUCTION and TRANSFORMATION operations, and how they determines a new URI creation, or a separate ownership, or both:

 
     Operation         | Separate    Separate 
                       | URI?        ownership?
     ------------------|--------------------------------
     REPRODUCTION      |  Yes        No 
     TRANSFORMATION    |  Yes        Yes
     ------------------|--------------------------------
 

Then we create the truth table of REPRODUCTION and TRANSFORMATION capabilities to identify each entry with four scope modifiers:

  
          REPRODUCTION  TRANSFORMATION | SCOPE is 
      ------------------------------------------------
           No            No            |  PRIVATE   
           Yes           No            |  PROTECTED  
           No            Yes           |  INTERNET
           Yes           Yes           |  PUBLIC
      ------------------------------------------------
 

The following table is the same than above, but it is possible to read it out in a more natural way.
The symbols '-' and '+' mean that the operation is denied, or allowed, respectively. The symbol '-' can be read like 'not', while the symbol '+' correspond to a silence (a consent).

 
      The resource is | When the resource can be
      ------------------------------------------------
       PRIVATE        | -REPRODUCED and -TRANSFORMED 
       PROTECTED      | +REPRODUCED but -TRANSFORMED 
       INTERNET       | -REPRODUCED but +TRANSFORMED 
       PUBLIC         | +REPRODUCED and +TRANSFORMED 
      ------------------------------------------------
 

This truth table shows clearly that the space allocated to the INTERNET modifier is a logical imperative of the semantics of interoperability.

3.1 PRIVATE modifier

The PRIVATE modifier means that no secondary URI, and no separate ownership are allowed for the resource. No reproduction, and no transformation are allowed.

By default, the exhibition and the execution of a PRIVATE resource is restricted to the rightsholder.

3.2 PROTECTED modifier

The PROTECTED modifier means that the reproduction of the resource is allowed under a client URI, but no separate ownership is granted. Reproduction is allowed, but transformation is forbidden.

The client resource inherits the same scope than server. By default, it is possible to make news reproductions of the client resource.

A protected resource is typically managed with a license. For example, a license can be used in a collective project that encourages the reproduction of the work. A protected license can even create a "mixed scope", by allowing some transformations capabilities to resources.

3.3 INTERNET modifier

The INTERNET modifier means that the transformation of the resource is allowed, but its reproduction is forbidden.

The INTERNET modifier can be defined as a "country excluder". This exclusion rationale highlights the fact that the server resource appears just like a private resource under the laws of all countries. In other words, the client version cannot be reproduced in any country, and its ownership is only recognized by the original rightsholder.

However, a separate ownership exists and the client version inherits the same scope than the server resource. For example, it is not possible (even to the original rightsholder) to reproduce the transformed version in any country.

Traditional ownership is built upon country reciprocity. The Internet scope shows that individuals can still enforce the resource ownership under a country exclusion. Otherness is also matter of individual, rather than of the countries.

To summarize, the Internet scope has three characteristics:

The Internet resource can also be managed by a license. For example, to authorize the reproduction of a specific version, based on the polling of readers.

Without the INTERNET scope modifier, it would be impossible to understand the widest part of the behavior of resources in interoperable environments, such as Internet.

3.4 PUBLIC modifier

The PUBLIC means that the reproduction and transformation of the resource is allowed under a client URI, and a separate ownership is recognized to derivative versions.

The client resource inherits the same scope than server. By default, the client resource is public.

PUBLIC scope must not be confused with "public domain". The rightsholder of the public resource keeps the full control on the resource.

3.5 Scope inheritance

The rule of scope inheritance is described in the following table. More advanced explanations on inheritance can be read in previous section (see "Reciprocity and Equivalence").

Given 2 resources, server and client, the scope modifier of the client declaration SHALL be either the same or a more restrictive modifier.

 
  Server      |      Client resource MAY be:
  resource is |   Private  Protected Internet Public 
  ----------------------------------------------------
  PRIVATE     |    Yes     --         --      --     
  PROTECTED   |    --      Yes        --      --     
  -----------------------------------------------------
  INTERNET    |    Yes     --         Yes     --     
  -----------------------------------------------------
  PUBLIC      |    Yes     Yes        Yes     Yes    
  -----------------------------------------------------
 

Notes:

This document does not define precedence rules for scope modifiers.



 TOC 

4. Syntax of ownership declarations

In previous chapters, we analyzed the semantics of interoperability, then we defined four scope modifiers for ownership declarations. This chapter describes the RECOMMENDED syntax of such declarations.

4.1 Formal declaration

The formal declaration is a multiline text. Server and client resources declarations share the same declaration syntax.

The syntax is based on three possible line types.

A server declaration contains a Property line and optionally, a License line:

              
 
   [modifier](C) [date][owner]              (Property line)
   [standard assertion or license link]     (License line)
 
 

A client declaration contains the same lines than the server declaration, plus one or more attribution lines:

              
 
   [modifier](C) [date][owner]              (Property line)
   & [modifier](C) [date][owner]            (Attribution line)
   [standard assertion or license link]     (License line)
 

Here is an example of an Internet client declaration:

 
    Internet(C) 2004, ClientOwner (client-owner@clientsite.com)
    & Internet(C) 2004, ServerOwner (server-owner@serversite.com)
    All rights reserved in all countries.
 

4.2 Property line

Property line MUST appear for all modifiers. The Property line is composed of:

              
 
            Modifier                 Scope   
            -------------------------------------
            (none)                  PRIVATE      
            [Private](C)            PRIVATE      
            Protected(C)            PROTECTED    
            Public(C)               PUBLIC       
            Internet(C)             INTERNET     
            -------------------------------------
 

In a compliant declaration, the (C) symbol MUST follow the scope modifier. The (C) symbol MUST appears even if no modifier is used or Country Law does not require it.

Two examples:

 
    Internet(C) 2004, OwnerName (owner-x@somesite.com)

    Public(C) 2002-2004, OwnerName (owner-x@somesite.com)
 

4.3 Attribution line

The Attribution line SHALL be used in an ownership declaration when the resource is a transformed version of the original or when multiple rightsholders share different rights on it.

The use of an AMPERSAND sign ('&') in front of Attribution line is RECOMMENDED.

The syntax of Attribution line is otherwise similar to the Property line. For example:

 
    Internet(C) 2004, OwnerC (http://www.clientC.com)
    & Internet(C) 2002-2004, OwnerB (http://www.client_server.com)
    & Public(C) 2002, OwnerA (http://www.server.org)
 

When multiple server resources have been used, or because there are multiple rightsholders, the ownership declaration may contain multiple attribution lines. For example:

              
 
   [modifier](C) [date][Local Rightsholder for the translation]             
   & [modifier](C) [date][Worldwide Rightsholder for all languages]   
   & [modifier](C) [date][Author who sold the original rights]            
   [standard assertion or license link]     
 

4.4 License line

License line is OPTIONAL and can be used with any modifier to override the default behavior of the resource.

The license line can be multiline and MUST close the ownership declaration, after the Property line and the Attribution line(s).

The license line is a free text that usually relies on conventional expressions, as used in the country of the protected resource.

 
    Private(C) 2004, Owner (http://www.clienttranslation.com)
    All rights reserved
 

Here is another sample in French.

 
    Internet(C) 2004, NomDuClient (http://www.client.fr)
    & Internet(C) 2002-2004, NomDuServeur (http://www.serveur.ca)
    Reproduction interdite
 

The license line can refer to a license identified by an external URI.

 
    Internet(C) 2004, OwnerX (owner-x@somesite.com)
    LGTv1r4: http://www.in3activa.org
 

4.5 Long names and short names of modifiers

Scope modifiers are chosen from a finite token list, with four elements: Private, Protected, Internet, Public.
All uppercase or lowercase variations are allowed and these variations do not modify the modifier semantics .

This document does not define localized names for these tokens. However, it defines short equivalents, as in the following table:

              
                                            
        Long name       Short name
        -------------------------------------
        Private(C)       pri(c)       
        Protected(C)     pro(c)       
        Public(C)        pub(c)       
        Internet(C)      int(c)       
        -------------------------------------
 

Here is a compliant handwritten implementation using short names:

    Int(C) 2004, RightsHolder ...

Note: usage of short equivalents is reserved to the handwritten implementation of the syntax. Metalanguage descriptions (such HTML or Dublin Core) MUST use long names for modifiers.



 TOC 

5. Scope modifiers implementation

After we analyzed the semantics of the interoperability of resources based on the pair (URI, ownership), we determined four scope modifiers, and proposed a recommended syntax to use the ownership declarations.

As a conclusion to this specification, this chapter describes three compliant implementations of the scope modifiers.

5.1 Handwritten implementation: the default modifier

The handwritten implementation matches the full syntax specification of scope modifiers. The handwritten implementation also allows the usage of short names of modifiers. For a complete handwritten implementation, see the previous chapter.

To follow the common usage in the countries of Berne Union, a compliant handwritten implementation SHALL consider the PRIVATE modifier as the default modifier.

The following declaration :

    (C) 2004, RightsHolder ..

will be interpreted as:

    Private(C) 2004, RightsHolder ...

5.2 HTML implementation: the SCOPE tag

Scope modifiers are well suited for automated processing by robots, and for dissemination of resources in the Internet. Among multiple possibilities, we define the HTML implementation [HTML40]W3C, Hypertext Markup Language 4.0 Specification, April 1998., because it can be easily adapter to other metalanguage specifications (XML, RDF, etc).

The RECOMMENDED implementation of this framework with the HTML 4.0 language MUST include:

The following example describes a protected HTML resource:

 
       <html>
       <head>
        ...
       <meta name  = "scope"
            content   = "internet" >
        ...
       </head>
       <body><pre>
          ...
       </pre></body>
       </html>
 

The content attribute defines the default scope of the resource. HTML body tags that define specific content boundaries may override this default scope

The following sample defines a Public scope portion, located inside the default Internet scope of the resource. Both syntax are allowed and MUST be recognized by automatic processing:

 
       <scope content="public"> ... <scope> 
  or
       <scope public> ... <scope>
 

5.3 Dublin Core implementation

The Dublin Core specification offers a richer layout for scope modifiers. This section describes the addition of the "scope" modifier to the Dublin core specification [RFC2731]Kunze, J., Encoding Dublin Core Metadata in HTML, RFC 2731, December 1999..

The addition is based on a new SCOPE element, to be used along with the already defined Rights Element:

 
      <html>
       <head>
       <title>Le ravissement d'Europe</title>
       <link rel     = "schema.DC"
             href    = "http://purl.org/DC/elements/1.0/">
       <meta name    = "DC.Title"
             content = "Charte in3ActivA de traducteurs...">
       <meta name    = "DC.Creator"
             content = "Robredo, I">
       <meta name    = "DC.Type"
             content = "Contrat">
       <meta name    = "DC.Date"
             content = "2004">
       <meta name    = "DC.Format"
             content = "text/html">
       <meta name    = "DC.Language"
             content = "fr">


       <meta name = "DC.Rights"
             lang   = "fr"
             content= "http://www.in3activa.org/doc/fr/LGT-FR.html">

       <meta name = "DC.Scope"
             content= "Internet">

       </head>
       <body><pre>
          ...
       </pre></body>
       </html>
 

This Dublin Core example would be equivalent to the following handwritten declaration (possibly inserted at the end of the resource):

 
    internet(C) 2004, I.Robredo
    http://www.in3activa.org/doc/fr/LGT-FR.html
 

5.4 Using licenses

The scope modifiers provide a powerful, although generic, framework for resources. To enlarge or restrict the scope of the resource ownership, the rightsholders may define a license and override the default behavior of scope modifiers.

For example, a license may override the protected scope of software resource, and it can authorize the resource transformation under specifics conditions.

Conversely, the license of an Internet resource can be provided to authorize the reproduction in some countries, such as the licensee's country. For example, the license attached to an Internet resource may allow a book reproduction to be sold in specific countries, without prejudice to the original ownership.

 
    (c) 2004, I.Maturana for the Spanish version
    &Internet (C) 1999-2004, I.Robredo 
    http://www.in3activa.org/doc/es/LGT-ES.html
 

The framework provided by scope modifiers introduces the opportunity for rightsholders to create and develop powerful licenses schemas, based on the analysis and the simulation of resource behaviors, in interoperable environments, including the Internet.



 TOC 

6. Security Considerations

None.



 TOC 

7 References

[BERNE] World Intellectual Property Organization, WIPO., "Berne Convention for the Protection of Literary and Artistic Works", Paris Act of July 24, 1971, as amended on September 28, 1979.
[CPPREF] Ellis, M. and B. Stroustrup, "The annotated C++ Reference Manual", 1990.
[HTML40] W3C, "Hypertext Markup Language 4.0 Specification", April 1998.
[IEEE 90] Institute of Electrical and Electronics Engineers, "IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY", 1990.
[LGT] Maturana, I. and I. Robredo, "General license of translation", 1990-2004.
[RDF] W3C, "Resource Description Framework Model and Syntax Specification", February 1999.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., Irvine, U. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", August 1998.
[RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin Core Metadata for Resource Discovery, RFC 2413", September 1998.
[RFC2731] Kunze, J., "Encoding Dublin Core Metadata in HTML, RFC 2731", December 1999.
[XML] W3C, "Extensible Markup Language (XML)", 2004.


 TOC 

Authors' Addresses

  I.Maturana
  in3activa
  Aptdo 15.117
  Madrid, Spain
  
  I.Robredo
  in3activa
  Ziburu, France


 TOC 

Intellectual Property Statement

Disclaimer of Validity

Copyright Statement

Acknowledgment