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 extent) 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
network.
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@mailman.nhm.ku.edu http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid