DSpace

Email Archive: dspace-architecture (read-only)

2008:	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug	_Sep (68)	_Oct (206)	_Nov (127)	_Dec (35)
2009:	_Jan (25)	_Feb (122)	_Mar (71)	_Apr (42)	_May (25)	_Jun (52)	_Jul (4)	_Aug (3)	_Sep	_Oct	_Nov	_Dec

[Dspace-architecture] Identifiers, URIs, Objects, Strings, etc

From: Dan Sheppard <dan.sheppard@ca...> - 2008-10-16 13:41

Dear all,

I hope you don't mind me butting in on this thread with perhaps an
outsider's perspective?

There seem to be a lot of things being discussed, all mixed together
(which is always the way), but it might help to consider them separately?

common base classes and interfaces
----------------------------------

I think the case has probably been made that it makes sense for a range
of objects in the data-model to have certain uniform functionality (such
as identifiability), if that would be useful for the project.

Graham's point in [1] that it could be an interface rather than a class
is a good one, I think. Inheriting by extension in java usually ends up
being troublesome, not least because you can only do it once, but also
because it doesn't really sit easily with current development practice
which will limit integrability going forward. This article[2] is a good
summary, if excessively rabid.

[1] dspace-architecture, Graham Trigg, 2008-10-14 15:21, para 4
[2] http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

underlying resentation
-------------------------

As I understand it, you've also been talking about mapping all data onto
an underlying uniform datastructure [3]. This is something which has
come up again and again in projects I've been involved with (and, I get
the imssion, all projects, everywhere!). And if it's got an easy
answer, I'm sure I don't know it!

Resenting everything in some uniform format can have some advantages
such as ease of resentation in serial formats, improved code-reuse,
uniformity, etc but on the other hand there's a penalty for type safety,
and often clarity of code. It's something that's even reasonably
entrenched depending on your programming language.

But as Graham points out in [4] having interfaces available shouldn't
tie the implementation: what we're after is being able to "see" these
things as either specific, typed, and well-named methods, or else as
abstract maps of properties.

Of course, there has to be one underlying implementation, and I'd be
marginally inclined to agree with Aaron in [5] that the language and
IDEs give you neat ways of working quickly and safely with objects which
are resented explicitly and separately and which are more painful to
use if merely "layered-on" at a higher level.

It would makes sense to me, though, that if you went down this route,
you'd probably need some kind of interface implemented on all
first-class objects (or, perhaps better, a
reflection-and-annotation-based equivalent) to be able to resent and
manipulate these disparate objects uniformly (eg for RDF).

[3] dspace-architecture, Graham Trigg, 2008-10-14 15:21, para 2,3
[4] dspace-architecture, Graham Trigg, 2008-10-14 15:21, para 4
[5] dspace-architecture, Aaron Zeckowski, 2008-10-14 15:02

strings as identifiers
----------------------

Bradley's message [6] matches my experience, too, when handling the
objects vs strings question. I always think it's really important to
remember that an "object" can be a simple string container, or else you
could have a complex, very constrained "string". Overall, I agree with
Bradley that it's important to work on defining the components (if any)
of an identifier before thinking about resentation.

An object resentation has advantages if the identifier syntax is
highly structured, and painful to parse because you only do it once, and
you get it right each time (eg URI), but a string has the advantage of
being simple to pass around, across and through environments.

Given the thoughts in this thread on "underlying resentation"
(above), it seems to make sense to me that a string resentation would
be a sensible default, along with some uniform means of DSpace
resurrecting an object on the basis of its identifier.

This is because I think the case has been made that you need both a rich
and also a string resentation, but the balance here is shifted for me
for identifiers from the earlier discussion of the objects themselves.
Identifiers are used as surrogates for objects, often because storing or
transmitting the object itself is impractical [7] (or nonsensical), and
so an "identifier object" is itself an object you will probably have to
stringify it at some point, anyway. Even to use the object
resentation of an identifier in reasonably internal service
interfaces stresses the SOA type approach of modularity by forcing
replacement services to "buy into" the data-model. And so it becomes
more difficult to plug in things (like caches) from third parties.

It probably makes sense, though, to also have some parsed object (by
analogy with java's URI) where a service can "very" internally parse and
serialise identifiers with the minimum of hassle and risk. (This object
could also containing means of creating the object it identifies).

The point at which you go from passing the "identifier object" around to
its string resentation is a judgement call, I think. But in the
inter-service layer, it makes sense to me to keep to strings.

[6] dspace-architecture, Bradley McLean, 2008-10-15 12:29
[7] dspace-architecture, Aaron Zeckowski, 2008-10-15 15:01

URIs as identifiers
-------------------

I'd be very nervous of using URIs as identifiers, as it seems to me that
Mark is making very good points in [8], that URIs are, these days, a
complex and subtle form of identifier. It makes sense to me that the
identifiers you have should have a URL resentation, but that this
shouldn't be the base form of these identifiers.

My main worry here is data orthogonality. URIs have many nooks and
strange places in which data can be shoved which could cause services to
behave erratically if misused. This is exactly the kind of issues that a
tight identifier specification is trying to avoid. For example, if you
use "http" in one identifier and someone writes "https" instead, what
will happen. We can come to a decision on what that means, or regulate
the protocol down to one instance, but how do we ensure that this is
correctly used/ignored and checked where appropriate across services?
Also, if we start using them in XSLT, etc, that could easily mess our
URIs up for similar reasons.

It seems to make sense that an identifier object which you might create
for /intra-/service use (a deserialised resentation of the
/inter-/service string identifier) should include a means of generating
a corresponding URI, or else something such as a URI service being able
to take an DSpace identifier string and return a URI and vice versa, but
not /be/ a URI. To make this a service would allow URI/identifier
mapping in challenging deployment situations.

[8] dspace-architecture, Mark Diggory, 2008-10-15 22:34

I hope this is of some use, and I've not just made the thread
pointlessly longer!

Dan.

Re: [Dspace-architecture] Identifiers, URIs, Objects, Strings, etc

From: Graham Triggs <graham@bi...> - 2008-10-16 16:04

I've never been quoted by paragraph before. I kind of like it.

Dan Sheppard wrote:
> [2] http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

What they've managed to avoid saying, but can be boiled down to is that
actually multiple inheritance is rather useful ;)

After skimming the article, there are a few points I could bring up that
are over simplified, one sided, and don't acknowledge the problems (in
some cases, the same problems) that can occur with interface inheritance
/ composition.

But then I'm not meant to be giving a critique on the article, and in
the general case, overall I agree with it. It just irritates me as it's
the kind of article that has people saying "yes, we must do everything
this way", and not engaging their brain.

> An object resentation has advantages if the identifier syntax is
> highly structured, and painful to parse because you only do it once, and
> you get it right each time (eg URI), but a string has the advantage of
> being simple to pass around, across and through environments.

How true is that really? What if your String contains non-ASCII /
control characters? How about composed vs decomposed diacritics?

URIs don't necessarily mean you can automatically disregard the problem,
but people can make an awful lot of assumptions about the ubiquity of
Strings.

> Identifiers are used as surrogates for objects, often because storing or
> transmitting the object itself is impractical [7] (or nonsensical), and
> so an "identifier object" is itself an object you will probably have to
> stringify it at some point, anyway.

Yes, if we used URIs, we would have to output a string resentation of
it at some points. But then we need to output URI strings of, well,
basically all identifiers in the system. And quite often.

> Even to use the object
> resentation of an identifier in reasonably internal service
> interfaces stresses the SOA type approach of modularity by forcing
> replacement services to "buy into" the data-model. And so it becomes
> more difficult to plug in things (like caches) from third parties.

An identifier should always implement Serializable (URI does), and
probably Comparable (URI does). If your identifier implements those too
interfaces, and you can't plug in a cache, then I would be asking
serious questions about the cache implementation.

Although you can always pull out the string resentation of the URI if
you absolutely have to in order to integrate with something.

> The point at which you go from passing the "identifier object" around to
> its string resentation is a judgement call, I think. But in the
> inter-service layer, it makes sense to me to keep to strings.

Oof. If you are calling remote services, then yes, you [probably] need
the string resentation to pass.

But in-process services can just take an object - in fact, that's
exactly what they are doing if you pass a string. Passing a parsed
object though gives you a few guarantees about what you are handling.
And it saves you some parsing / validation on every service call - and
there will be numerous handovers between in-process services.

> I'd be very nervous of using URIs as identifiers, as it seems to me that
> Mark is making very good points in [8], that URIs are, these days, a
> complex and subtle form of identifier. It makes sense to me that the
> identifiers you have should have a URL resentation, but that this
> shouldn't be the base form of these identifiers.

Ahem... definitely NOT URL resentation! But, essentially every
identifier in the system has to be describable as a URI. It's very hard
to find a case where that won't be necessary somewhere, given the
assertions that we need to make about the objects.

> My main worry here is data orthogonality. URIs have many nooks and
> strange places in which data can be shoved which could cause services to
> behave erratically if misused. This is exactly the kind of issues that a
> tight identifier specification is trying to avoid. For example, if you
> use "http" in one identifier and someone writes "https" instead, what
> will happen. We can come to a decision on what that means, or regulate
> the protocol down to one instance, but how do we ensure that this is
> correctly used/ignored and checked where appropriate across services?
> Also, if we start using them in XSLT, etc, that could easily mess our
> URIs up for similar reasons.

Yes, you can shove data in often overlooked bits of URIs. But then
Strings have no rules at all, and you can easily misuse them if you want.

There is nothing to stop someone writing https into a string identifier
instead of http. And what do you do with it then? Once you've asserted
an identifier as a URI, you can normalize it or use a number of
strategies to assert equivalence - that's not as easy with just Strings.

And no, I'm not advocating regulating protocols. We might be talking -
in some cases - about something as simple as an opaque URI [with a
private / unregistered schema].

G

This e-mail is confidential and should not be used by anyone who is not the original intended recipient. BioMed Central Limited does not accept liability for any statements made which are clearly the sender's own and not exssly made on behalf of BioMed Central Limited. No contracts may be concluded on behalf of BioMed Central Limited by means of e-mail communication. BioMed Central Limited Registered in England and Wales with registered number 3680030 Registered Office Middlesex House, 34-42 Cleveland Street, London W1T 4LB
This email has been scanned by Postini.
For more information please visit http://www.postini.com

Re: [Dspace-architecture] Identifiers, URIs, Objects, Strings, etc

From: Dan Sheppard <dan.sheppard@ca...> - 2008-10-16 17:21

Graham Triggs wrote:
> I've never been quoted by paragraph before. I kind of like it.
>
> Dan Sheppard wrote:
>> [2] http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
>
> What they've managed to avoid saying, but can be boiled down to is that
> actually multiple inheritance is rather useful ;)

Useful and dangerous. For example, there's the problem of the
inheritance diamond: multiply inheriting from the same base class.
There are plenty of C++ developers who curse it (I was once one of them).

But that's only the point covered on the first page. The fragile base
class (pages two to four) is much more dangerous (as they point out on
page two).

> After skimming the article, there are a few points I could bring up that
> are over simplified, one sided, and don't acknowledge the problems (in
> some cases, the same problems) that can occur with interface inheritance
> / composition.
>
> But then I'm not meant to be giving a critique on the article, and in
> the general case, overall I agree with it. It just irritates me as it's
> the kind of article that has people saying "yes, we must do everything
> this way", and not engaging their brain.

It's certainly polemical, and not a well-balanced article, I agree (I
did say that it was a bit rabid). But it does sent the case
reasonably directly.

>> An object resentation has advantages if the identifier syntax is
>> highly structured, and painful to parse because you only do it once, and
>> you get it right each time (eg URI), but a string has the advantage of
>> being simple to pass around, across and through environments.
>
> How true is that really? What if your String contains non-ASCII /
> control characters? How about composed vs decomposed diacritics?

Ah, I see what happened here. Where I said "(eg URI)" above I meant eg
the java URI object. If you start passing that around you only parse the
URI once and get it right each time. A string form (including string
forms of URIs) "the advantage of being simple to pass around, across and
through environments".

Yeah, if you start passing around Laotian vowel signs separated by
teletype control codes you're going to have a bad day at the office! :)

That whole section of my message was about "handling the
objects vs strings question", not for or against URIs which is an
orthogonal question (in a later section), and has examples of each kind
of resentation (serialization and java.net.URI).

> An identifier should always implement Serializable (URI does), and
> probably Comparable (URI does). If your identifier implements those too
> interfaces, and you can't plug in a cache, then I would be asking
> serious questions about the cache implementation.

Were you thinking about using the identifiers in a key context, rather
than only a value one? Personally, I'd be nervous of something keyed
based on its serialization form.

One of the goals of OO is to hide implementation, particularly in data
field member terms: how data is resented internally should be
transparent. That's very difficult to achieve with serialization (though
possible, you can only verify that property by looking at the
implementation, and so relying on it!). A URI which acts identically in
two circumstances could well have a different internal form (perhaps a
legacy of its method of creation). This would almost certainly have a
different serialised form, and so a different cache slot. Distributed
fast caches use O(1) inserts via hash algorithms, so Comparable isn't
much use. To show that multiple hashing is impossible relies on looking
at, and relying on, a particular private implementation.

> Ahem... definitely NOT URL resentation! But, essentially every
> identifier in the system has to be describable as a URI. It's very hard
> to find a case where that won't be necessary somewhere, given the
> assertions that we need to make about the objects.

Yes, that makes sense to me. Every identifier must be /exssible as/ a
URI.

> Yes, you can shove data in often overlooked bits of URIs. But then
> Strings have no rules at all, and you can easily misuse them if you want.

I'm not sure anyone was suggesting that any string the user invents is a
valid identifier. The idea is to have data orthogonality, every valid
thing has one resentation, and all other resentations are not
legal. A structured string, like a URI. Except that with a URI as a
native format, it's very difficult to ensure that all the cases have
been covered. It doesn't seem reasonable to ask someone using
identifiers to identify and read all of the relevant RFCs on URIs just
to ensure they use URIs correctly. They're just way too complex
entities, now, to easily use as stock-in-trade.

> And no, I'm not advocating regulating protocols. We might be talking -
> in some cases - about something as simple as an opaque URI [with a
> private / unregistered schema].

I don't think many people would have problems with that, as it amounts
to a structured string.

But say you use java.net.URI and so getRawSchemeSpecificPart() to get
your identifier from your opaque scheme. That's close to what Bradley
was characterising as a "string in an object". The difference is that
say some misbehaving service sets the scheme incorrectly, or doesn't set
it at all. I'm assuming that every service doesn't check the scheme
part, so it's mainly used as a scheme in a box. But then someone writes
an XSLT thing, or uses it for hashed lookup, and all of a sudden it
fails, but only for URIs written by that faulty service. Because you're
passing around objects with concavities for dirt, all of a sudden you
have to manage the potential dirt in those concavities by writing extra
unit tests in services wherever a URI object is outgoing, or else rely
on subtle breakages across service boundaries.

Dan.

Re: [Dspace-architecture] Identifiers, URIs, Objects, Strings, etc

From: Mark Diggory <mdiggory@mi...> - 2008-10-16 23:42

On Oct 16, 2008, at 5:27 AM, Dan Sheppard wrote:

> Dear all,
>
> I hope you don't mind me butting in on this thread with perhaps an
> outsider's perspective?

Certainly... your welcome to comment.

> There seem to be a lot of things being discussed, all mixed together
> (which is always the way), but it might help to consider them
> separately?
>
> common base classes and interfaces
> ----------------------------------
>
> I think the case has probably been made that it makes sense for a
> range
> of objects in the data-model to have certain uniform functionality
> (such
> as identifiability), if that would be useful for the project.
>
> Graham's point in [1] that it could be an interface rather than a
> class
> is a good one, ...

Yes, it is certainly my intention to see this remain an interface
driven prototype.

>
> underlying resentation
> -------------------------
>
> As I understand it, you've also been talking about mapping all data
> onto
> an underlying uniform datastructure [3]. This is something which has
> come up again and again in projects I've been involved with (and, I
> get
> the imssion, all projects, everywhere!). And if it's got an easy
> answer, I'm sure I don't know it!

We're architecting a API and Service for storing content and metadata
about it. This API architecture evolved based on a required need in
the community to have greater flexibility in attaching metadata
properties to any portion of the older DSpace 1.5 Data Model
(Collection, Item, Bitstream, etc)

>
> Resenting everything in some uniform format can have some
> advantages
> such as ease of resentation in serial formats, improved code-reuse,
> uniformity, etc but on the other hand there's a penalty for type
> safety,
> and often clarity of code. It's something that's even reasonably
> entrenched depending on your programming language.
>
> But as Graham points out in [4] having interfaces available shouldn't
> tie the implementation: what we're after is being able to "see" these
> things as either specific, typed, and well-named methods, or else as
> abstract maps of properties.

We have 3 primary types in the model, they have corresponding
mappings to the current implementations we hope to use as possible
storage mechanisms(JCR, RDF, Fedora, etc).

See:
https://dspace.svn.sf.net/svnroot/dspace/dspace2/trunk/api/src/main/
java/org/dspace/model

org.dspace.model.Literal
Any "literal" value (as opposed to a reference to a Resource). All
Literals have a datatype (meaning RDF and XSD datatypes)

org.dspace.model.Resource:
A namespace qualified local name (i.e. a URI) that can be used as a
reference or a Resource description.

org.dspace.model.Asset
An Asset "is" a java.util.Set<org.dspace.model.Property> and extends
org.dspace.model.Resource it is "the type" returned from the
Repository Service and maps explicitly to a JCR Node or RDF Named
Graph, I.E. it is a Set of Property Statements with a URI identifier.

org.dspace.model.Property
Is basically a RDF triple resenting any statment asserted in the
above "Named Graph".

With this set of Interfaces it is possible to exss every
association and attribute exssed within the original DSpace 1.5.x
Data Model, but with the flexibility of not hardcoding that original
Data Model (which was basically an ontology, like Fedoras, EPrints/
SWAP, FRBR, BIBO, etc). Thus it opens the door to allowing the
codebase (and conversely its developers) to exit the debate about who
has got the best resentational ontology... DSpace becomes
agnostic, no matter if we are talking FRBR, SWAP, MARC/MODS, DCMI,
BIBO... The common need being to store your content and describe it
as you see fit.

> Of course, there has to be one underlying implementation, and I'd be
> marginally inclined to agree with Aaron in [5] that the language and
> IDEs give you neat ways of working quickly and safely with objects
> which
> are resented explicitly and separately and which are more
> painful to
> use if merely "layered-on" at a higher level.
>
> It would makes sense to me, though, that if you went down this route,
> you'd probably need some kind of interface implemented on all
> first-class objects (or, perhaps better, a
> reflection-and-annotation-based equivalent) to be able to resent
> and
> manipulate these disparate objects uniformly (eg for RDF).

I think this is a case of trying to make the store "hyper generic",
in which case its sounding more and more like an Object store. There
are certainly enough of those out there that we don't need to be
competing with. That stretches a bit beyond both are current
architectural requirements and needs IMO.

> strings as identifiers
> ----------------------
>
> Bradley's message [6] matches my experience, too, when handling the
> objects vs strings question. I always think it's really important to
> remember that an "object" can be a simple string container, or else
> you
> could have a complex, very constrained "string". Overall, I agree with
> Bradley that it's important to work on defining the components (if
> any)
> of an identifier before thinking about resentation.

As I've state viously, my current only need for identifiers is as
references for looking up Assets and referencing their Resources.

>
> An object resentation has advantages if the identifier syntax is
> highly structured, and painful to parse because you only do it
> once, and
> you get it right each time (eg URI), but a string has the advantage of
> being simple to pass around, across and through environments.
>
> Given the thoughts in this thread on "underlying resentation"
> (above), it seems to make sense to me that a string resentation
> would
> be a sensible default, along with some uniform means of DSpace
> resurrecting an object on the basis of its identifier.
>
> This is because I think the case has been made that you need both a
> rich
> and also a string resentation, but the balance here is shifted
> for me
> for identifiers from the earlier discussion of the objects themselves.
> Identifiers are used as surrogates for objects, often because
> storing or
> transmitting the object itself is impractical [7] (or nonsensical),
> and
> so an "identifier object" is itself an object you will probably
> have to
> stringify it at some point, anyway. Even to use the object
> resentation of an identifier in reasonably internal service
> interfaces stresses the SOA type approach of modularity by forcing
> replacement services to "buy into" the data-model. And so it becomes
> more difficult to plug in things (like caches) from third parties.
>
> It probably makes sense, though, to also have some parsed object (by
> analogy with java's URI) where a service can "very" internally
> parse and
> serialise identifiers with the minimum of hassle and risk. (This
> object
> could also containing means of creating the object it identifies).

You argue both points here... both the final statement is that the
implementation validate and parse String identifiers.

https://dspace.svn.sf.net/svnroot/dspace/dspace2/trunk/api/src/main/
java/org/dspace/model/ValueFactory
https://dspace.svn.sf.net/svnroot/dspace/dspace2/trunk/api/src/main/
java/org/dspace/service/RepositoryService

These both allow the underlying implementation to manage both the
validation of the "string" resenting the identifier and the
optimal creation of its parsed form (Asset and/or Resource).

>
> The point at which you go from passing the "identifier object"
> around to
> its string resentation is a judgement call, I think. But in the
> inter-service layer, it makes sense to me to keep to strings.
>
> [6] dspace-architecture, Bradley McLean, 2008-10-15 12:29
> [7] dspace-architecture, Aaron Zeckowski, 2008-10-15 15:01
>
> URIs as identifiers
> -------------------
>
> I'd be very nervous of using URIs as identifiers, as it seems to me
> that
> Mark is making very good points in [8], that URIs are, these days, a
> complex and subtle form of identifier. It makes sense to me that the
> identifiers you have should have a URL resentation, but that this
> shouldn't be the base form of these identifiers.

The base form of the identifier is up to the underlying storage
mechanism. But, based on the constrain I'm imposing, it needs to be
resentable as an Asset and/or Resource described above, and in
that case, it needs a "namespace" and a "local name". When exposing
to applications... that will be rendered as a URI (the syntax, not
the java.net.URI object).

> My main worry here is data orthogonality. URIs have many nooks and
> strange places in which data can be shoved which could cause
> services to
> behave erratically if misused. This is exactly the kind of issues
> that a
> tight identifier specification is trying to avoid. For example, if you
> use "http" in one identifier and someone writes "https" instead, what
> will happen. We can come to a decision on what that means, or regulate
> the protocol down to one instance, but how do we ensure that this is
> correctly used/ignored and checked where appropriate across services?

I feel its still upto the implementation and the consuming application.

> Also, if we start using them in XSLT, etc, that could easily mess our
> URIs up for similar reasons.

Yes, if they are in content serialized to XML and transformed by XSL
tooling (i.e. a consuming application) they need to be treated
appropriately according to the syntax and rules of the XML
serialization and XSL transformation pipeline.
>
> It seems to make sense that an identifier object which you might
> create
> for /intra-/service use (a deserialised resentation of the
> /inter-/service string identifier) should include a means of
> generating
> a corresponding URI, or else something such as a URI service being
> able
> to take an DSpace identifier string and return a URI and vice
> versa, but
> not /be/ a URI. To make this a service would allow URI/identifier
> mapping in challenging deployment situations.

The DSpace trunks ObjectIdentifier/ExternalIdentifier implementation
currently provides this capability.
>
> [8] dspace-architecture, Mark Diggory, 2008-10-15 22:34
>
> I hope this is of some use, and I've not just made the thread
> pointlessly longer!

Not at all, well, others may have differing opinions ;-)

Cheers,
Mark
~~~~~~~~~~~~~
Mark R. Diggory
Home Page: http://purl.org/net/mdiggory/homepage
Blog: http://purl.org/net/mdiggory/blog

Re: [Dspace-architecture] Identifiers, URIs, Objects, Strings, etc

From: Graham Triggs <graham@bi...> - 2008-10-16 23:46

Dan Sheppard wrote:
> There are plenty of C++ developers who curse it (I was once one of them).

Not trying to sound smug here, but I've developed C/C++ applications for
over 10 years and never had an inheritance problem (and yes, I did use
multiple inheritance).

> But that's only the point covered on the first page. The fragile base
> class (pages two to four) is much more dangerous (as they point out on
> page two).

Hello? I've made a really brain dead decision to extend a Class that
implements some similar properties to ones that I want, but is
fundamentally a different entity. Why has my program suddenly broken? ;)

> Ah, I see what happened here. Where I said "(eg URI)" above I meant eg
> the java URI object. If you start passing that around you only parse the
> URI once and get it right each time. A string form (including string
> forms of URIs) "the advantage of being simple to pass around, across and
> through environments".

Yes, and that parsing / getting it right is what I want to benefit from.
You know the syntax is valid, and you can perform some validations very
easily. It's trivial to then turn it into it's string resentation
when necessary (ie. for [out-of-process] transfer / display).

Inside a process, you are passing an object either way - at least with a
URI you can assume it is an identifier, and you won't accidentally pass
an arbitrary string in it's place. Type safety is a wonderful thing ;)

> Yeah, if you start passing around Laotian vowel signs separated by
> teletype control codes you're going to have a bad day at the office! :)

In DSpace 1.x, we do comparison of filenames, and we have a worldwide
community - implementing in multiple languages. Precomposed vs
decomposed may not be that arbitrary - and a good way to waste a few
hours wondering why two strings that are displayed identically in the
debugger can't be matched.

> Were you thinking about using the identifiers in a key context, rather
> than only a value one? Personally, I'd be nervous of something keyed
> based on its serialization form.

Not necessarily keyed on it's serialization (although that may be a
possibility, for which you may want to evaluate the implementation
carefully). But if the cache supports writing to disk, or clustering,
then the keys and values will [probably] need to be serializable.

> A URI which acts identically in
> two circumstances could well have a different internal form (perhaps a
> legacy of its method of creation). This would almost certainly have a
> different serialised form, and so a different cache slot. Distributed
> fast caches use O(1) inserts via hash algorithms, so Comparable isn't
> much use. To show that multiple hashing is impossible relies on looking
> at, and relying on, a particular private implementation.

Well, there are components of a URL that may differ between instances,
and yet may act (resolve) to the same entity. But then the string
resentation of those URIs/URLs would also be different.

Simply using strings doesn't mean that you can assert identity or
equality on equivalent identifiers.

> I'm not sure anyone was suggesting that any string the user invents is a
> valid identifier. The idea is to have data orthogonality, every valid
> thing has one resentation, and all other resentations are not
> legal. A structured string, like a URI. Except that with a URI as a
> native format, it's very difficult to ensure that all the cases have
> been covered. It doesn't seem reasonable to ask someone using
> identifiers to identify and read all of the relevant RFCs on URIs just
> to ensure they use URIs correctly. They're just way too complex
> entities, now, to easily use as stock-in-trade.

But we've already stated/accepted that every identifier will need to be
exssed as a URI - we need URIs in RDF, should have URIs in DC
metadata - so we can't avoid dealing with it.

Yes, there are things you need to take into account. But what are you
more likely to get right - using the URI object (where it takes into
account encoding rules, and basic structue), or
handling/manipulating/creating a String resentation?

> But say you use java.net.URI and so getRawSchemeSpecificPart() to get
> your identifier from your opaque scheme. That's close to what Bradley
> was characterising as a "string in an object". The difference is that
> say some misbehaving service sets the scheme incorrectly, or doesn't set
> it at all. I'm assuming that every service doesn't check the scheme
> part, so it's mainly used as a scheme in a box.

If you have a String, you still have to define some kind of
resentation(s). What if that includes a fix/scheme, and a
misbehaving service sets it incorrectly?

> But then someone writes
> an XSLT thing, or uses it for hashed lookup, and all of a sudden it
> fails, but only for URIs written by that faulty service. Because you're
> passing around objects with concavities for dirt, all of a sudden you
> have to manage the potential dirt in those concavities by writing extra
> unit tests in services wherever a URI object is outgoing, or else rely
> on subtle breakages across service boundaries.

I'm not going to claim that it's impossible to mis-create a URI object.
But I think it's being over-estimated the amount of places you would be
creating them from component parts - ie. a plain uuid or issn - if the
use was pervasive through the system.

If each DSpaceAsset is identified with a URI, such that I retrieve it
with the URI, then the only place that URI [should] need to be created
from scratch is in the assetstore provider. If there is a bug, then more
than likely you won't be able to create the asset.

References in indexes, assertions about the object, relationships to the
object made in the metadata will all come from the URI - it may be the
toString() resentation of it, but you know that will new URI()
correctly (and that's all I ever have to do with it - new URI() the
string and pass the object around). All the references, assertions and
relationships will be consistent and valid.

Now, if you just have Strings, you need to create a URI resentation
to make/disseminate assertions about it, and assert a relationship to
it. What if you fail to create a correct/valid URI resentation at
that point? Are your assertions nonsensical? Do you have relationships
that don't link to the intended object?

If you have some misbehaving code in the creation of a URI, what
situation would you rather be dealing with - an asset not being created,
or assets in the store with what is to all intents and purposes corrupt
metadata?
This email has been scanned by Postini.
For more information please visit http://www.postini.com

Re: [Dspace-architecture] Identifiers, URIs, Objects, Strings, etc

From: Dan Sheppard <dan.sheppard@ca...> - 2008-10-17 11:19

Mark Diggory wrote:
> You argue both points here... both the final statement is that the
> implementation validate and parse String identifiers.

I think that's right: I think that all the issues that you're dealing
with here are interesting judgment calls which come up over and again in
other projects (which is why I was interested in the thread). Aaron
pointed out that you were discussing these questions in passing (knowing
I had an interest in them from vious discussions and arguments), so I
thought I would put in my $0.02.

I'd be interested to hear what Brad decides on these issues, :).

Dan.

DSpace

Email Archive: dspace-architecture (read-only)

About SourceForge

Find Software

Develop Software

Community

Help