[Tdwg-guid] Annotation and Link Out

Benjamin H Szekely bhszekel at us.ibm.com
Fri May 19 07:49:09 CEST 2006

Hi Steve,
    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.

1.) Resolution Burden

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.

   i) The functionality can be, and is already built into the Java client. 
  ii) Caching at all points can greatly improve performance (even though 
FAN information and metadata can change, it can still be cached to some 
  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
       to foreign metadata services because these services could 
change....we use LSID resolution to provide a level indirection against 
this problem. 
2.) Attribution of assertions

(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. )

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. 

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...

3.) Spam

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. 

Now I will try to address some of your 9 points below

> 1.)  An authority is never allowed to make an assertion whose subject is 

> an LSID that it is not authoritative for.

I truly believe that requirements such as these fly in the face of the 
flexibility of RDF. 

> 2.)  LSIDs authoritatively attribute an assertion to the organization 
> that owns the fully qualified authority domain (this includes sub 
> domains to support the case of hosted authority services)

This is definitely true for metadata services pointed to by the 
authoritative WSDL.

> 3.)  Objects are not distributed across authorities but instead link to 
> other first-class objects that may exist within other authorities.

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.

> 4.)  Annotations, corrections, etc. are valuable, and as such should be 
> first class objects that are attributed to their issuers by the normal 
> process of 2 above.  This is annotation as linking; the subject of the 
> annotation is the LSID of the annotation, it is attributed to the 
> authority of the issuer, and an agreed upon predicate is used to define 
> the object that acts as domain of an annotation (what it applies to). 
> This guarantees correct attribution of annotations throughout the 

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.)

> 5.)  We cannot stop spammers from publishing malicious assertions but we 

> can validate a given assertion acquired from some source external to the 

> LSID system by resolving the LSID and checking the resulting metadata 
> against the assertion.  Spammers will find it difficult to circumvent 
> this method because it requires hijacking the DNS system.  If you trust 
> that a source gave you a complete and full copy of an object you don't 
> have to resolve its LSID.

I don't have much to offer here.  This is something I look forward to 
discussing together. 

> 6.)  We will often have to use systems that are external to LSID in 
> order to find the data/metadata we're interested in (at the very least 
> to identify LSIDs to resolve).  These other systems have to understand 
> how to attribute assertions to their owners and can do so using the 
> rules above without relying on metadata about a foreign authority.

Certainly we can use other systems for annotation discovery but why not 
use LSID mechanisms as much as possible?

> 7.)  We don't have to assume (as FAN does) that an authority is 
> responsible for providing all information in the universe that relates 
> in any way to its LSIDs

Agreed, but the authoritative source is the best place to start.

> 8.) If you get back invalid metadata from an authority (not incorrect, 
> but metadata that, for example, violates a functional property 
> restriction), you automatically know who is at fault (the organization 
> that owns the authority name).

With FAN, this work as well...when you download Foreign metadata, you can 
validate it before merging with your main model.

> 9.) A FAN style notification system could still be used for logging and 
> tracking the use of one's data or for proposing corrections to and 
> issuer who might want to approve and incorporate those suggestions into 
> their published data.

Neat idea!


I look forward to discussing this further with you.

- Ben

> So we might use a FAN-like system, but only for foreign annotation 
> notification, not foreign authority notification.
> Any comments?  Have I misunderstood the assumptions behind FAN?
> -Steve
> _______________________________________________
> TDWG-GUID mailing list
> TDWG-GUID at mailman.nhm.ku.edu
> http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20060519/509311a5/attachment.html 

More information about the tdwg-tag mailing list