In the arts, the

pathetic

fallacy is the act of ascribing human feelings to inanimate objects. 

We argue that the same fallacy is turning up on the semantic web---that

researchers are (perhaps subconsciously) allowing the computer's internal

representation of data to influence the way their tools present information to

users, when instead they should developing interfaces that are based on the

users' needs, independent of the computer's particular information

representation.





In the following discussion, we will look at some examples of the pathetic

fallacy in terms of the interaction challenge of


• 
  
  what knowledge these graphs communicate,
  
  
• 
  
  what tasks they support, and
  
  
• 
  
  whether these are the optimal paradigms for such communication and tasks.
  
  






From this context, we investigate two questions:  Are graphs the right

default representation for the Semantic Web?  And if not, how

might we think about default presentations for the Semantic Web in order to

make accessible its promised benefits for knowledge building and sharing?

Scalable Highly Expressive Reasoner

A technology that provides ontology analytics (OWL-DL without nominals) over highly expressive ontologies.

The Neurocommons project seeks to make all scientific research
materials - research articles, annotations, data, physical materials - as available and as useable as they can be.
We do this by both fostering practices that render information in a form that promotes uniform access by computational agents - sometimes called "interoperability". We want knowledge sources to combine meaningfully, enabling semantically precise queries that span multiple information sources.

Our work covers general data and knowledge sources used in computational biology as well as sources
specific to neuroscience and neuromedicine.
The practices that we develop and promote are designed to play well on the Semantic Web. We view our technical work not as creating a new service or content library, although we do both, but rather as helping to promote the growth of semantically linked scientific information.

How should one go about finding documentation that will explain what a URI names, in cases where this is needed and it is not already at hand? HTTP was not designed to help out here, so the following is not as elegant as would be a protocol designed with this in mind.

If you're doing bulk processing of URI documentation, you may be better off doing bulk downloads or SPARQL queries on an appropriate SPARQL endpoint, as large numbers of probes will be inefficient and will load servers, usually unnecessarily.

The following protocol is designed to be forgiving enough to grandfather many URIs already in use on the Semantic Web, such as those in the RDF Schema vocabulary and Dublin Core, while strict enough to support our URI requirements. It coincides with HTTP in the absence of overrides, responses containing a Location: header, and 200 responses.

SHAME is a library that leverages editors, presentations and query interfaces for resource centric RDF metadata.
The central idea of SHAME is to work with Annotation Profiles which encompasses:




• how the metadata in RDF should be read and modified.
  
• what input is allowed, e.g. multiplicity and vocabularies to use.
  
• presentational aspects like order, grouping, labels etc.
  

These annotation profiles are then used to generate user interfaces for either editing, presentation or querying purposes.
The user interface may be realized in a web setting (both a jsp and velocity version exists) or in a stand alone application (a java/swing version exists).