Exhibit's expressions (e.g., .author.school) are composed out of
property IDs, which cannot be arbitrary strings because they need to fit
into the expression syntax. They should not contain spaces, period,
exclamation mark, and parentheses. The expression parser was admitted
written in haste and will surely be replaced by something substantially
more robust. Right now, I'd recommend using only letters, numbers,
dashes, and underlines in property IDs. Full URIs used as property IDs
will almost certainly cause problems.
I am aware of the error "'property' has no properties'" (which is caused
by improperly parsed property IDs) and will get to it eventually. Right
now, please go with "safe" property IDs and make sure that the property
IDs used in various Exhibit expressions actually exist in your data.
If you want a nicer time debugging Exhibit, include it with bundle=false
<script src=".../exhibit-api.js?bundle=false"></script>
This will give you individual files instead of the bundled .js file.
Cheers,
David
carmen wrote:
> On Sat Mar 17, 2007 at 11:13:34AM +0000, Keith Alexander wrote:
>
>> Hi again folks,
>>
>> I realised that the semantic templating idea I discussed in my last post
>> to this list could also be applied to Exhibit's JSON database format,
>> and that this could provide a pretty neat bridge between an Exhibit and
>> an RDF database.
>>
>
> i tried doing this the other day, as i want to move the view generation in my
> RDF-based app-development framework to the client, since i am moving the
> server over to a minimal endpoint/glue(mongrel and redland) role. at this
> point i need a clientside model cache and template engine and some
> sorting/filtering, so i figured id just use Exhibit since its already written.
>
> well i got close, but get errors like "'property' has no properties" deep in
> the bowels of the exhibit that i have no idea how to fix (line number of the
> error in firebug is for the console.print() function) - i read most of the
> it, and its a total JAVA clusterfuck - really smart people can often hold so
> much structure and abstraction in their head that the resulting solution is
> far from simple; couple that with the 'throw more classes at it' JAVA
> programmer mentality and its not hard to see how you ended up with a quarter
> meg (between the exhibit and simile-ajax libraries) just for some table
> sorting stuff which is way over the top - looking at integrating my ajax
> editors into this meant id have to use its idioms, and work within it's code,
> which is a no go (i dont make any claims to be a great programmer, but i had
> to read the JQuery source afterwards to settle down)..
>
> still, i want to get it working, as an option especially when 'exporting' the
> data for serverless exhibit purposes..
>
>
> i'm just using absolute URIs for all the properties to start with since i
> figured it could handle arbitrary strings. is that the problem?
>
>
> it should also be noted that metaweb uses basically the same format as
> exhibit and mentioned on
> http://semwebdev.keithalexander.co.uk/blog/posts/Exhibit-JSON.html . JSON
> pattern for query, a similar pattern back to substitute into a clientside
> template. where Exhibit uses string predicates, MQL uses absolute paths like
> /cars/modelyear and RDFa uses namespaced or absolute URIs... so theres a lot
> of overlap and it should be trivial to make any tool support all three..
>
> _______________________________________________
> General mailing list
> [email protected]
> http://simile.mit.edu/mailman/listinfo/general
>
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
