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

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

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


Subject: req doc [was: agenda for ER teleconference 20001127]


At 10:29 2000 11 27 -0800, Lauren Wood wrote:
>Technical discussion on the requirements document, as sent out
>previously.
>
>Any amendments to the requirements document.

I assume this refers to the document dated Nov 10 at
http://lists.oasis-open.org/archives/entity-resolution/200011/msg00002.html
Correct me if there is a later version.

General comment:

The requirements are all in terms of mapping "to URIs."  I'm not
sure this is quite right.  TR9401 refers to the (datatype of the)
right-hand side as "storage object identifier" or soi which is a
superset of URIs.  The problem with restricting the rhs to URIs
is that it doesn't allow for the rhs to be a file name (since some
file systems allow file names with characters that are not allowed
in URIs, and escaping the character is not an option since that would
be a different file name in such operating systems) nor does it allow
the rhs to be, say, a call to a database, and this is a requirement
of a catalog for many of my customers.

I suggest we use the term soi, at least in the requirements document, 
to give us the added flexibility for now.

Regarding the suggested requirement:

>The catalog must provide the ability to delegate mapping 
>of classes of public identifiers and URNs to alternate catalogs.

I suggest we delete the "and URNs" part.  I don't want to map 
URNs/URIs qua URNs/URIs at all. 

Regarding the suggested requirement:

>The catalog must provide the ability to map URIs to alternate URIs 
>(for example, namespace names).

While I think that mapping namespace names is probably reasonable,
I am opposed to the wording that suggests that we are mapping
URIs in general.  I suggest we delete this requirement.  

We could perhaps replace it with one that says something about 
namespace names, or we could just handle namespace names as 
something upon which we all agree to include in the V1.0 catalog 
regardless of whether it is in the requirements documents.

paul


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


Powered by eList eXpress LLC