Re: [ESDS] Interaction models for Discovery Services

["Kenneth R. Traub" <[e-mail]>]

> In practice, all currently defined EPC identifier schemes have URI
representations (in fact URNs) - although it is conceivable that a URL could
be used as the identifier (although a URN, Digital Object Identifier (DOI)
or Handle might be less 'fragile' or more likely to be maintained for
long-term resolution).

If an enterprise wishes to create a private identifier, the HTTP URI scheme
is the easiest to use.  All  the enterprise needs is an Internet domain
name, which of course can be obtained rather inexpensively and easily.
There need not be a web page corresponding to that HTTP URL -- it can just
be used as a unique identifier.

In contrast, it's rather difficult for an enterprise to get URNs for private
use.  Registering a new URN namespace with IANA is a tortuous process, and
may take several years to complete.  It's a little easier to apply for a
Private Enterprise Number (PEN) which may be used with OID URNs of the form
urn:oid:1.3.6.1.4.1....  But these are limited to a numeric (though
hierarchical) structure, and are also somewhat obscure.

So... I would indeed expect to find URLs as identifiers, specifically HTTP
URLs used when a single enterprise or small organization wants to use
private identifiers or otherwise embed an existing numbering system into URI
syntax.


> ... The EPCglobal Tag Data Standard defines URI patterns for EPC
identifiers in which wildcard characters  (*) or [lo-hi] ranges indicate
which absolute URIs should match the specified pattern ... Not sure whether
this is based on an established convention for URI patterns (Ken would know
this) - but either the same approach could be adopted for non-EPC URI
patterns - or regular expressions could be used ...

There is no established convention for URI patterns, to my knowledge.  Of
course, many operating systems have a wildcard syntax for filenames, so it's
easy to imagine URI patterns for the file: URI scheme (though I don't
believe the file: scheme actually defines a pattern syntax).

What we did for EPC was entirely ad hoc.

We purposely avoided a powerful syntax like regular expressions, however,
because that presents considerable implementation difficulty.  It's easy to
create a database schema in which EPC patterns can be searched efficiently
(you add columns for each of the individual EPC components, and then a given
pattern translates into a set of conjoined equality or inequality clauses on
each such column).  It would be quite difficult to do that for regexps,
unless the database had built-in support for regular expressions of equal or
greater expressive power.


> The XSD schema files for the Application Level Events (ALE) and EPC
Information Services (EPCIS) standards developed by the EPCglobal community
do not in fact constrain an EPC to be anything other than a URI - so it
seems quite likely that a future EPCglobal standard for Discovery Services
would take a similar approach of 'any URI' for EPCs or individual IDs.

That's entirely true for EPCIS, and indeed I'm familiar with many EPCIS
deployments that use non-EPC URIs (often HTTP URLs as described above).

The situation for ALE is a little different, because where EPCs appear in
ALE they are initimately tied to reading or writing to an RFID tag.  So the
only URIs that may be used there are ones for which a translation to binary
form is defined in the EPC Tag Data Standard; ie, EPC Tag URIs or EPC "raw"
URIs.


> Using structured identifiers and in particular URIs and URI patterns could
have advantages in the operations of a Discovery Service, since URI patterns
could be used as a convenient shorthand for registering or querying about
multiple IDs that have a common URI prefix and a contiguous range of serial
numbers.  They could also be helpful for any high-level indices that might
be used for expressing the scope or identifier types / ranges handled by a
particular DS.

Again, there is no general definition of "URI patterns".  So any notion of
URI pattern matching would have to be defined on a per-URI scheme basis, or
even on a smaller scope (e.g., urn:epc:id:... defines one pattern syntax,
but urn:foobar:... might define a different one).


> Regarding ensuring global uniqueness, as Ken pointed out in his earlier
e-mail, it is possible to prepend a non-URI string with a URI prefix in
order to qualify its namespace and thereby construct a globally unique URI
identifier from a combination of one or more locally unique identifier
strings.

Though to achieve global uniqueness, one can't just prepend any old URI
prefix.  One has to fit the non-URI string into an established URI scheme
that's properly registered with IANA and any other lower-level registration
authority mandated by that scheme.  As noted before, registering a new URI
scheme or URN namespace is probably only within the reach of an industry
consortium or standards body.  HTTP URIs are the easiest thing for
individual enterprises or small organizations, as the only registration
necessary is the purchase of a domain name.

Ken

---
Ken Traub Consulting LLC
[phone]
[e-mail]


_______________________________________________
ESDS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/esds