- From: John Black <JohnBlack@deltek.com>
- Date: Mon, 2 Aug 2004 13:20:14 -0400
- To: "Dan Brickley" <danbri@w3.org>, "Phil Dawes" <pdawes@users.sf.net>
- Cc: <www-rdf-interest@w3.org>
> From: Dan Brickley > Sent: Thursday, July 29, 2004 3:47 PM > > * Phil Dawes <pdawes@users.sf.net> [2004-07-29 17:52+0000] > > > > Hi All, > > > > I've noticed that some RDF specs (including FOAF and DOAP) use > > inverseFunctional properties instead of URIs to identify instance > > resources. > > > > I can see an instant benefit in doing this - end users don't need to > > worry about the problems of minting URIs, maintaining them etc.. > > > > Is this the way RDF is going - URIs for the schema, BNodes with > > InverseFunctional properties for the instancedata? > > What are the consequences? > > I think we'll always need both. > > In FOAF I've tried to be pragmatic. When "what is 'the' URI for a > person" silliness was holding up deployment, FOAF encouraged an > emphasis on reference-by-description techniques. OWL subsequently gave > us a way of expressing simple reference-by-description > strategies in a > machine readable way. But FOAF doesn't rule out the > possibility of their > being URIs for people, companies, etc. It just doesn't let > the current > lack of such things get in the way. > > Rob McCool and Guha in their TAP work take a similar line, advocating > reference-by-description as a useful strategy for merging Web data. > http://tap.stanford.edu/tap/rbd.html > http://tap.stanford.edu/sw002.html > > I think in the early days of RDF there was something of a fairytale > quality to the way URIs were perceived - basically a myth that all > interesting and description-worthy things will have well-known URIs. > FOAF and reference-by-description in general shouldn't be taken as an > attack on URIs as such, but as advocacy that other techniques are > useful too, and that we can write applications that figure out > common references without all parties necessarily sharing the > same URIs > or even identifying expressions. > > All that said, we've a long way to go before all RDF toolkits support > InverseFunctional-based identity reasoning "out of the box"... This weekend I have been reading with interest the two above mentioned references as well as the other papers by R. Guha, et al, "Object Co-identification on the Semantic Web", http://tap.stanford.edu/CoIdent.pdf "Disambiguating People in Search", http://tap.stanford.edu/PeopleSearch.pdf, "Semantic Negotiation: Co-identifying Objects Across Data Sources", http://www.daml.ecs.soton.ac.uk/SSS-SWS04/02.pdf, and others. This is great stuff! I Have been working on some ideas about Semantic Web technologies, and I found these papers precisely elucidate and address one of the problems I have come up against, the difficulty in establishing common knowledge, in the sense used in epistemic logic, of the reference of URIs. In the "Conclusions" section of the paper, "Object Co-identification on the Semantic Web", the author says, "Finally, we are investigating the applicability of these techniques beyond simple object matching to matching property types and classes". I have searched for and found but one paper reporting on investigations of this problem. Has anyone else? Can anyone point me to any papers that have been published about this? I am very interested in this since in all of the above papers, the simplifying assumption is made that common knowledge has already been achieved with respect to Class, Property, and Constant terms. In my work, I am trying to eliminate these assumptions, thus the reference by description technique would require semantic negotiation or other means for establishing (or operating effectively without) common knowledge of the sense of those terms as well. In the following paper, "Semantic Negotiation: Modeling Ambiguity in Dialogue". http://www.doc.ic.ac.uk/~sgc/papers/pease_edilog02.pdf, The authors are focusing on examples that seem to be very much like reconciling differences in the semantics of classes. John Black > Dan
Received on Monday, 2 August 2004 13:20:32 UTC