<br><font size=2 face="sans-serif">Hi Steve,</font>
<br><font size=2 face="sans-serif"> I think you have a very
strong grasp of the FAN system. FAN is of course just a proposal
so I would be happy to work with any interested parties in comming up with
a more useful specification. However, for now, I will go on the defensive
to see what (if anything) we can keep in the current spec. I will
try to address your three main concerns, though you had some interesting
subtle points as well.</font>
<br>
<br><font size=2 face="sans-serif">1.) Resolution Burden</font>
<br>
<br><font size=2 face="sans-serif">Fan resolution may seem expensive, but
in reality it requires an additional getMetadata() call to get the forieign
authorities. However, in the general case, a client might have to do several
getMetadata() calls given the authoritative WSDL anyway. Fan then
requires a getAvailableServicesCall() and (possibly) many getMetadata()
calls for every foreign authority. Let me point out a few mitigating
factors in the seemingly expensive and complicated operation.</font>
<br>
<br><font size=2 face="sans-serif"> i) The functionality can
be, and is already built into the Java client. </font>
<br><font size=2 face="sans-serif"> ii) Caching at all points can
greatly improve performance (even though FAN information and metadata can
change, it can still be cached to some extent)</font>
<br><font size=2 face="sans-serif"> iii) If you think about it, FAN
lays out the minimal amount of work necessary to resolve metadata hosted
by another entity. We can't have the main authority point directly</font>
<br><font size=2 face="sans-serif"> to foreign
metadata services because these services could change....we use LSID resolution
to provide a level indirection against this problem. </font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">2.) Attribution of assertions</font>
<br>
<br><font size=2 face="sans-serif">(This is the only point where I might
come off as a bit rough so I apologize in advance. :) I also apologize
if I have misunderstood your argurments on this point. )</font>
<br>
<br><font size=2 face="sans-serif">To restrict who can say what about URIs
in the semantic web is dangerous and eventually impossible. Adding
a layer of indirection as suggested in requirement #3 is unnecessary when
viewing the RDF graph as a whole. Also, where would such a triple
live? It shouldn't be in the main metadata so you would end up with
somethng isomorphic to FAN metadata. </font>
<br>
<br><font size=2 face="sans-serif">Alternatively, consider the following.
Because the main authority refers to the foreign authority, it does
not mean that it fully endorses the foreign metadata as true statements
about the LSID in question. In fact, because metadata is used to
list the foreign authorities, it can include qualifications about the foreign
sources, such as, I don't trust this one, or this one is 50% trustworthy..etc...</font>
<br>
<br><font size=2 face="sans-serif">3.) Spam</font>
<br>
<br><font size=2 face="sans-serif">If a given authority allowed anybody
to register itself as a foreign authority without advising FAN enabled
clients of its untrustworthiness, then yes, spamming would be a problem.
But certainly, we can imagine a trust-based registration system,
where trusted sources could register as foreign authorities, and the FAN
metadata would label them as such. Anonymous sources would be either
denied or flagged in the FAN metadata. </font>
<br>
<br>
<br><font size=2 face="sans-serif">Now I will try to address some of your
9 points below</font>
<br>
<br><tt><font size=2><br>
> 1.) An authority is never allowed to make an assertion whose
subject is <br>
> an LSID that it is not authoritative for.</font></tt>
<br>
<br><tt><font size=2>I truly believe that requirements such as these fly
in the face of the flexibility of RDF. </font></tt>
<br><tt><font size=2><br>
> 2.) LSIDs authoritatively attribute an assertion to the organization
<br>
> that owns the fully qualified authority domain (this includes sub
<br>
> domains to support the case of hosted authority services)</font></tt>
<br>
<br><tt><font size=2>This is definitely true for metadata services pointed
to by the authoritative WSDL.</font></tt>
<br><tt><font size=2><br>
> 3.) Objects are not distributed across authorities but instead
link to <br>
> other first-class objects that may exist within other authorities.</font></tt>
<br>
<br><tt><font size=2>It's a bit dangerous to think of resources as distributed
objects. A URI is a URI, and anybody in the world can refer to it
or make statements about it.</font></tt>
<br><tt><font size=2><br>
> 4.) Annotations, corrections, etc. are valuable, and as such
should be <br>
> first class objects that are attributed to their issuers by the normal
<br>
> process of 2 above. This is annotation as linking; the subject
of the <br>
> annotation is the LSID of the annotation, it is attributed to the
<br>
> authority of the issuer, and an agreed upon predicate is used to define
<br>
> the object that acts as domain of an annotation (what it applies to).
<br>
> This guarantees correct attribution of annotations throughout the
network.</font></tt>
<br>
<br><tt><font size=2>I don't disagree that some annotations might need
to be formal and seperate structures. (In fact, we have a system
built that can do this in a rather elegant fashion.)</font></tt>
<br><tt><font size=2><br>
> 5.) We cannot stop spammers from publishing malicious assertions
but we <br>
> can validate a given assertion acquired from some source external
to the <br>
> LSID system by resolving the LSID and checking the resulting metadata
<br>
> against the assertion. Spammers will find it difficult to circumvent
<br>
> this method because it requires hijacking the DNS system. If
you trust <br>
> that a source gave you a complete and full copy of an object you don't
<br>
> have to resolve its LSID.</font></tt>
<br>
<br><tt><font size=2>I don't have much to offer here. This is something
I look forward to discussing together. </font></tt>
<br><tt><font size=2><br>
> 6.) We will often have to use systems that are external to LSID
in <br>
> order to find the data/metadata we're interested in (at the very least
<br>
> to identify LSIDs to resolve). These other systems have to understand
<br>
> how to attribute assertions to their owners and can do so using the
<br>
> rules above without relying on metadata about a foreign authority.</font></tt>
<br>
<br><tt><font size=2>Certainly we can use other systems for annotation
discovery but why not use LSID mechanisms as much as possible?</font></tt>
<br><tt><font size=2><br>
> 7.) We don't have to assume (as FAN does) that an authority
is <br>
> responsible for providing all information in the universe that relates
<br>
> in any way to its LSIDs</font></tt>
<br>
<br><tt><font size=2>Agreed, but the authoritative source is the best place
to start.</font></tt>
<br><tt><font size=2><br>
> 8.) If you get back invalid metadata from an authority (not incorrect,
<br>
> but metadata that, for example, violates a functional property <br>
> restriction), you automatically know who is at fault (the organization
<br>
> that owns the authority name).</font></tt>
<br>
<br><tt><font size=2>With FAN, this work as well...when you download Foreign
metadata, you can validate it before merging with your main model.</font></tt>
<br><tt><font size=2><br>
> 9.) A FAN style notification system could still be used for logging
and <br>
> tracking the use of one's data or for proposing corrections to and
<br>
> issuer who might want to approve and incorporate those suggestions
into <br>
> their published data.</font></tt>
<br>
<br><tt><font size=2>Neat idea!</font></tt>
<br>
<br><tt><font size=2>></font></tt>
<br><tt><font size=2>></font></tt>
<br><tt><font size=2>></font></tt>
<br>
<br><tt><font size=2>I look forward to discussing this further with you.</font></tt>
<br>
<br>
<br><tt><font size=2>- Ben</font></tt>
<br>
<br><tt><font size=2><br>
> So we might use a FAN-like system, but only for foreign annotation
<br>
> notification, not foreign authority notification.<br>
> <br>
> Any comments? Have I misunderstood the assumptions behind FAN?<br>
> <br>
> -Steve<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> TDWG-GUID mailing list<br>
> TDWG-GUID@mailman.nhm.ku.edu<br>
> http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid<br>
</font></tt>