Fwd: DAWG Use Case: Browser

This is a use case from Nick Gibbins, the guy who write the generic RDF
browser for 3store. It coveres optional binding and presumably
tell-me-about + a number of other things.

- Steve

----- Forwarded message from Nick Gibbins <nmg@ecs.soton.ac.uk> -----

> The Advanced Knowledge Technologies project has built a general-purpose RDF
> browser that complements its 3store RDF repository. This browser makes use
> of the query facilities provided by 3store to present the contents of a
> knowledge base in a human-readable fashion, and on a per-resource basis.
> 
> 1. Browser basics
> 
> A browsing session begins with the user making a simple query that specifies
> either a resource URI, or a literal value that is to be searched for:
> 
> http://triplestore.aktors.org/browse/
> 
> If a literal query is executed, the browser displays all the resources that
> have a literal-valued property whose value matches that given in the query:
> 
> http://triplestore.aktors.org/browse/?literal=Gibbins
> 
> If a resource query is executed, the browser displays all the information
> that the repository holds on that resource:
> 
> http://triplestore.aktors.org/browse/?resource=http%3A%2F%2Fwww.ecs.soton.ac.uk%2Finfo%2F%23person-01269
> 
> This information is displayed in two columns; the left column lists the names of
> those properties which have values for this resource, and the right column lists
> the values of those properties. Both incoming and outgoing properties (which
> point to or from the resource under examination) are displayed. The former are
> displayed with a left-pointing arrow to indicate that they have the reverse
> sense (the value displayed is the subject of the triple, rather than the
> object). The triple patterns which are used to generate this view for a resource
> query are as follows:
> 
> (RESOURCE, ?property, ?value)
> (?value, ?property, RESOURCE)
> 
> where RESOURCE is the resource URI given in the browser query
> 
> 2. Optional matching
> 
> If a resource-valued property is displayed, the browser preferentially displays
> a human-readable name for the property value by searching for rdfs:label triples
>  for that value. If no such label exists, the URI of the resource is displayed.
> 
> When this behaviour is combined with the queries from the previous section, we
> would like to be able to specify a single query which matches statements
> involving the queried resource, and the relevant human-readable names, if any exist:
> 
> (RESOURCE, ?property, ?value)
> (?value, <rdfs:label>, ?label)
> 
> REQUIREMENT: it should be possible to specify that certain triple patterns
> within a query are optional
> 
> 3. Statement origins and source provenance
> 
> The information presented by the browser may have originated in more than
> one RDF file. The browser is able to indicate the origins of each statement
> presented, depending on whether the user has chosen to show sources, or
> hide sources. We refer to the source of a statement as its origin or context.
> Such an origin will typically be the URI of the RDF file from which the
> statement originated, which provides a mechanism for attaching coarse-grained
> provenential metadata to statements, by making statements about the origin URI.
> This adds a third column to the browser display, which displays the name of the
> source for each statement.
> 
> http://triplestore.aktors.org/browse/?resource=http%3A%2F%2Fwww.ecs.soton.ac.uk%2Finfo%2F%23person-01269&showSource=1
> 
> [[[ given that 'context' is a seemingly contentious word, probably best to only
> refer to 'origin' or 'source' here.
> 
> also, we're assuming that the granularity of statement origins is file-level;
> proposals for alternative RDF syntaxes which allow for multiple named graphs
> within one file will change this ]]]
> 
> REQUIREMENT: it should be possible to determine the origins of the statements
> which satisfy a given triple pattern
> 
> [[[ in 3store, we have extended RDQL syntax to add an optional fourth component
> to each triple pattern that is bound to the URI of the origin of matching
> statements. there may be other suitable approaches to satisfying this
> requirement, so we've been circumspect in the language we've used here ]]]
> 
> 4. Distinct query answers
> 
> If the sources are hidden, and the browser is displaying multiple
> statements which are identical, and differ only in their origins, only one
> statement is shown.
> 
> REQUIREMENT: It should be possible to specify whether only distinct answers to a
> query are to be returned.
> 
> [[[ the analogy here is with SELECT DISTINCT in SQL ]]]

----- End forwarded message -----

-- 
Stephen Harris                    07970 557047
AKT, IAM Research Group          023 8059 8347
University of Southampton, UK
swh@ecs.soton.ac.uk     http://www.aktors.org/

Received on Thursday, 20 May 2004 12:24:31 UTC