Subject: Service, Server, Dataset

From: Leslie Daigle <[email-masked]>
Date: Thu, 1 Jun 2000 08:24:49 -0400

Howdy,

The bit of conceptual basis that I particularly want to challenge
is this:

Nicolas Popp wrote:
> old terminology (service URI as a logical identifier for the service. A
> service spans one "dataset", even if a dataset can be the logical
> combination of multiple physical "datasets".

I don't think this is always the case.

A service has a goal; users use a service because of an expectation
that it will serve their needs, literally.  That expectation may
be based on any number of things -- it's the one that they know
about, it has a reputation for coverage, a reputation for precision,
it's cheap, it has quality data, whatever.  As I understand it,
Realnames is providing a service (or perhaps even several).

A dataset is, specifically, a collection of data tied together by
some relationship -- semantic, ownership, registration space, whatever.
The dataset is identified in a globally unique fashion (where "global"
really means the scope in which it is going to be seen, not
necessarily physically world-wide -- see examples below).
A service may draw on a single dataset, or several.  For example,
a service may partition the service into different datasets
based on category.  Or, a service may elect to swap one or more
of its datasets with other services based on trade agreements --
e.g., for mirroring purposes, use in a WAP "portal service", etc.
The dataset is typically the "smallest chunk" of data that will be
mirrored (I can't think of a reason for mirroring parts of datasets,
but that may be my lack of imagination).

A server is operated under the auspices of a single service, and
may serve one, some or all of that service's datasets.

If we don't have an explicit means of calling out the dataset id:

E.g., Realnames agrees to mirror its trademark data at some other
_service_.

        . When a client gets a whack of referrals, it has no way to
          determine whether any or all of the referrals cover the
          same data (i.e., only one needs to be followed) -- Roland's
          point.  Using "category" here does not answer the problem,
          because the client still can't tell if it's different
          data in the same category, or the same data mirrored.
          Need that globally-unique identifier.

        . Realnames doesn't have the opportunity to have the other
          organization indicate that it is using Realnames data --
          because the service object says "this is my data", not
          "I'm serving you Realnames data".

If we attempt to conflate service and dataset into one:

        . Yes, you can offer different services for different databases
          and make the split.  But, you still don't have the
          ability to make the link between Realnames offering the
          data, and some other licensed party offering coverage
          of it -- because the other party will report its serviceURI,
          not Realnames'.

        . You have to run each service on a different server,
          making it ugly to let a user search across all the
          datasets you offer (except by using referrals among your
          servers, etc)

Interesting issues:

        . We've said that _services_ differentiate themselves
          based on how they elect to handle such things as matches
          across languages, character matches, etc.

          In principle, then, the same dataset offered by different
          services may yield different results on searching
          (because different matching rules are applied).

          So maybe this doesn't answer Roland's request, directly.  But,
          it opens interesting possibilities for offering different
          qualities of service over the same advertized dataset
          ("I'll go to Realnames because I've had more success in
          using their service than I have had at OrgX's service,
          and they both cover the same dataset." -- service
          differentiation, again).

Service and dataset are two distinct conceptual things, and they
may intermix in most interesting ways.  I don't accept that we
can casually conflate the two concepts.  If we deprecate one in
favour of the other, we have to be darn clear what behaviours we
are disallowing.

I appreciate the goal to keep the protocol simple, and I think I have
a counter proposal -- but in keeping with my earlier remarks, I
would like to see discussion of the conceptual level (as outlined
above) before getting back to "how can we tweak this in the protocol".

Leslie.

--

-------------------------------------------------------------------
"My body obeys Aristotelian laws of physics."
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 2 Jun 2000 16:08:25 -0400

Well, after that rousing e-discussion(*), here's the proposal (clarified
and improved by an out-of-band discussion with Michael):

        . bring back serviceURI in the service object, but only
          as a _service_ URI (not fudging for datasets)

        . create a new "well-known" property in the document:
          datasetURI, which is meant to be a unique identifier
          for (not location of) a dataset.

Uses/convention:

        . any result MAY be tagged with the dataset it is
          from (because datasetURI is a property)

        . the service object MAY include the one or more datasetURIs
          for the datasets it covers

        . query URIs can be properly focused to individual datasets
          because datasetURI is a property (cf Nico's points re.
          "path" in URI, earlier this week)

        . results MAY contain more than one service object for
          a single service, so that individual service<->datasetURI
          bindings can be referenced in results and referral
          objects

        . referrals:  if the service object id'ed in a referral
          object contains more than one datasetURI, the client
          CANNOT assume that the hit was in both datasets --
          it could have been in one or the other.

For example:

   <?xml version="1.0"?>
   <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN">
   <cnrp>
        <results>
             <service id="0">
                  <serviceuri>http://acmecorp.com</serviceuri>
                  <dataseturi>urn:oid:1.2.3.4.666.5.4.3.1</dataseturi>
             </service>
             <service id="1">
                  <serviceuri>http://acmecorp.com</serviceuri>

<dataseturi>urn:oid:1.2.3.4.666.10.9.8.7.6</dataseturi>

             </service>
             <service id="2">

<serviceuri>http://servers.anothercorp.co.uk</serviceuri>
                  <dataseturi>urn:oid:1.2.3.4.666.5.4.3.1</dataseturi>

             </service>
             <resource>
                       <commonname>Fidonet</commonname>
                       <id>1333459455</id>
                       <resourceuri>http://www.fidonet.ca</resourceuri>
                       <serviceref ref="0" />
                       <description>This is ye olde Canadian
                          Fidonet</description>
             </resource>
             <resource>
                       <commonname>Fidonet</commonname>
                       <id>1333459455</id>
                       <resourceuri>http://host:port/bla</resourceuri>
                       <serviceRef ref="1" />
             </resource>
             <referral>
                 <serviceRef ref="1" />
             </referral>
        </results>
   </cnrp>

This enables the concept of datasetURI, without _requiring_
implementation of by services, and without perturbing top-level
CNRP.

Are there proposals for improvement of this, or do people think
that cnrp SHOULD NOT support the concept of datasets?

Leslie.

(*) NOT!
--

Leslie Daigle
[email-masked]

---

From: Michael Mealling <[email-masked]>
Date: Fri, 2 Jun 2000 17:26:06 -0400

> that cnrp SHOULD NOT support the concept of datasets?

After noodling on this abit, the only improvement I could think of would
be to make the dataset object peer (as far as the xml is concerned)
with the serviceURI and allow (not require) it in the actual
referral and resourcedescriptor objects.

I.e.:

The referral tag which looks like this right now:
<!ELEMENT referral (serviceRef)>
<!ELEMENT serviceref EMPTY>
<!ATTLIST serviceref ref IDREF #IMPLIED>

Which looks like this <referral><serviceref ref="1" /></referral>

would look like this:

<!ELEMENT referral (serviceRef)>
<!ELEMENT serviceref EMPTY>
<!ATTLIST serviceref ref IDREF #IMPLIED>
<!ATTLIST serviceref dataseturi CDATA "">

Giving us this:
<referral><serviceref ref="1" dataseturi="foo:bar" /></referral>

The reason why this is an improvement is because a) it still doesn't
require datasets to exist b) its easier to parse and get to. The parsing
required to get to a property withing a referenced Service isn't
trivial and if the dataset is there and important it should be closer
to the thing that needs it....

I.e. if we decide that its important enough to add as a well known
property then I suggest we go ahead and make life for the poor developer
easier by making it available with less effort....

-MM

--
--------------------------------------------------------------------------------
Michael Mealling        |      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions       |          www.lp.org          |  [email-masked]