Lessons learned from playing with the
KendraBase prototype:
Slots vs. ontology
- Defining object types and "slots" is a different job to defining ontology
- We are at the moment primarily concerned about
- first: defining object data types, and then Web interfacing
- secondly: gluing those slots to an ontology, as per first thoughts
"Document" vs. view
Dealing with the "sea of triples" world:
- the W3C Semantic Web model has an idea of "document" that groups things together
- it's a natural place to hook modification dates, author etc.
- think in terms of programming languages, with hierarchy of line, procedure, module, etc.
- what is our equivalent?
However,
- we have an idea of "views" on a sea of information
- our views correspond very roughly to W3C-type documents
- but we want to have far more fine-grained attribution of information
W3C document idea:
- pro: n3 is quite readable by experts and can be written and edited like a programming language -- we lose this paradigm by going to a fine-grained model, unless we want to "flatten" the fine-grained data
- con: RDF is almost totally unreadable, even by experts, seems to be intended for generation from a database anyway, so are we losing anything?
- BUT: we can choose to "flatten" the data if we like, effectively choosing to "own" the assertions as our own. This makes cut-n-paste editing possible.. v. v. important.
Thinks:
- imagine "semantic rich text", which will not only hold metadata like font and style info, but also semantic information from its publisher...
- can we do this as part of the HTML/CSS framework, eg. by encoding the semantic info via CSS class attributes... so that ordinary HTML editors will pass it through, and we can recover it on the other side?
Version control
- If external triples are mutable, what happens to our data when referenced triples change?
- When we have multiple views containing the same triple, what are the semantics? Copying, or reference?
- Do we need/want complex version control?
Caching
Confusion between two concepts:
- caching as an accelerator, to eliminate need to follow URL links
- caching as an archival system, to keep authoritative copies of old information
- accelerator caching fails soft
- but archival caching needs to know how far to traverse...
- idea of document/view would be useful here???