Re: An ontology for graphical user interfaces

> In a typical scenario a GUI would be generated based on the data that needs
> to presented, predefined UI-patterns, application-specific GUI guidelines,
> context information, etc. Based on all these inputs, a reasoner could then
> offer a representation of the form to be represented to the user. Using a
> mapping of this representation to an implementation, one could then
> visualise the form. I am currently working on an xHTML / AJAX based demo.
>
> For this, I am looking for previous ontology work to model the field of
> graphical user interfaces. Google has not been very helpful yet.

tried swoogle? i found its result quality horrible, but accoording to their blog they recently updated the index - maybe it sucks less these days..

are you looking to specify the entire app in RDF? transormations, templates, queries, input slots/forms?

one thing i found lacking was specifying such things in RDF. at first glance it might seem like the golden hammer pattern, but if you want to build 
something like Squeak with a consistent data model and be able to reuse the same structures to manipulate/persist/view instance data as well as the app 
configuration and behavior itself, it makes a lot of sense.

i maen, i couldnt find any schema to express DOM nodes in RDF, which was needed for templating, so i just made one up. same goes for CSS, resource-level 
permissions, and SPARQL queries. bits of SIOC and FOAF were useful to describe the users, otherwise, there were few reuse vectors.

i ended up with 3 layers of focus, as far as views are concerned. literal level, resource level, and multiple-resources level:

 literal level meaning, 
theres a property attached to the predicate, describing the default datatype for the object, eg money, text, resource, datetime.. this simplified the 
implementation wrt using XSD^^datatypes even though no XML tech is used otherwise even for storage or transformation, or getting typed literals in 
scripting languages and serialization formats where 'everything is a string' anyways.. 

resource level meaning a unified subject, and a property on it or any of its parents describing whether to use a domain-specific GUI (eg EMail) or a DOM 
template (RDFa with the about= property added dynamically and objects substituted into content= and inner textnodes based on the property= attribute) 

multuiple resources level is similar, pointing to different default views, like spreadsheet-table, SVG graph, or template (typically some preview format 
with just a title and modified and abstract attribute)

also i had to add properties to existing schemas where they made sense, rather than start a new one. i think ultimately swoogle and the like needs to 
evolve so it finds predicates and resources specified somewhere besides the dereferencable version, so eg, the FOAF people can realize everyone 
has a TwittrID attached to their account and they might want to add it to the canonical schema..

both SPARQL and DOM nodes required a 'order' property on subnodes, particularly in where clauses and siblings inside an element. this is mildly annoying 
as it requires touching all the subresources on any edit, but i think its a fact of life..


at least this is what i arrived at over the course of about 6 months of on and off tweaking of a metaweb/dabbleDB style app designed as a replacement 
for Ruby on Rails: http://whats-your.name/yard . after 'completing' the Camping ( sort of a minimalist rails without the J2EE baggage) version, i 
decided the next step was to eliminate ruby except as a glue between the webserver (Mongrel) and the store (Redland). so its highly broken right now as 
im rewriting DOM generation in javascript, and eventually want it to work with multiple endpoints (but honestly havent read the SPARQL endpoint spec 
yet, so right now its a combination of normal HTML forms and PATCH via JSON..)

fwiw, after deciding to switch to JS, i came up with this JSON format:

[{uri: 'http://whats-your.name/carmen', 'http://doac.net/experienced': 'http://doac.net/experience/unspecified'},{uri:'http://resource2..'}]

which is similar to the metaweb (which uses absolute paths to an unspecified root, eg '/people/pornstars' or '/cars/german/mercedes') and Exhibit (which 
useas words as the predicates, then an optional lookup table to map them to URIs). i havent dealt with namespaces in any way, since ive found once you 
have easy tools for schema reuse, you end up with such a mismash (and its not like we're writing code when working with the environment - the goal is 
decidedly different than activeRDF), eg a basic blog post was already using SIOC, DC-core, DC-elements, FOAF, SKOS, and a few others. for labels i just 
use the last word in the URI, after any #s or /s, which encourages making something readable in the first place.

this JSON format is also decidedly different than everything i saw mentioned on Lee Feigenbaum's recent JS discussions which tended more towards 
serializing raw triples into JSON, rather than resources..

and thats about it - let me know what you come up with !
c

Received on Sunday, 1 April 2007 18:03:16 UTC