dneary: Desktop Search Hackfest/Design Discussion moved to Desktop Search Hackfest/Design discussion: Capitalisation

dneary — Mon, 09 Nov 2009 13:48:39 GMT

Desktop Search Hackfest/Design Discussion moved to Desktop Search Hackfest/Design discussion: Capitalisation

← Older revision

Revision as of 13:48, 9 November 2009

generalantilles: Categorization

generalantilles — Thu, 30 Oct 2008 18:05:37 GMT

Categorization

← Older revision		Revision as of 18:05, 30 October 2008
Line 59:		Line 59:

	xesam:Author linking up document authors, creators and senders from simple string with name case to complex sender address case. linking up		xesam:Author linking up document authors, creators and senders from simple string with name case to complex sender address case. linking up
		+
		+
		+	[[Category:Community]]
		+	[[Category:Development]]

84.22.107.11 at 14:06, 19 September 2008

84.22.107.11 — Fri, 19 Sep 2008 14:06:23 GMT

← Older revision		Revision as of 14:06, 19 September 2008
Line 1:		Line 1:
	Points:		Points:
		+
	95% use cases should be sufficient:		95% use cases should be sufficient:
	find example:		find example:

84.22.107.11: New page: Points: 95% use cases should be sufficient: find example: (1)usually you remember where a file is located, that's 95% of use cases however if you don't, you use recursive search too...

84.22.107.11 — Fri, 19 Sep 2008 14:03:20 GMT

New page: Points: 95% use cases should be sufficient: find example: (1)usually you remember where a file is located, that's 95% of use cases however if you don't, you use recursive search too...

New page

Points:
95% use cases should be sufficient:
find example:
(1)usually you remember where a file is located, that's 95% of use cases
however if you don't, you use recursive search tool and it's extremely useful despite being very slow
(2)if you replace slow recursive tool with a fast indexer-based search, you get the pain
threshold lower and capture much more use cases than the slow tool, effectively making
"remember where a file is located" much less than 95% use cases.

There's a feedback loop: the better is implementation of particular functionality the more it is used,
which in turn increases use case % of things previously considered a corner case to the point of it becoming important.

Query language limits ontology, this causes ontology split between nepomuk and xesam:
Often you can model undelying data using either a more natural and flexible approach, which uses advanced QL
or a restricted approach which can work fine with basic QL

However users of simple QL don't get any benefits from the flexible representation, while losing the ability to efficiently
query it even in cases covered by the simple model. This causes them to push "simplification" of the ontology thus causing ontology split

consequences of the split. pros and cons of xesam as nepomuk base vs xesam<->nepomuk adapter
(1) Split in base ontologies causes split in user/extension ontologies, thus causing the split in the user base as well
(2) Ontology development tends to diverge. Details lose coherence, which coupled with stability requirements means more compatibility headaches
(3) compatibility-by-wrapper tends to be reactive -- changes, quirks etc eventually get ported over to the wrapper
compatibility-by-design is proactive
(4) parallel development of 2 ontologies means doubled effort and means twice(roughly) more bugs in each of ontologies.
(5) compatibility-by-wrapper encourages of divergence by decoupling onto development proceses from each other

Nepomuk vs xesam different maturation pace
which is also encouraged by compatibility-by-wrapper.

Basically this means that convergence is impossible in near and mid-term. Eco system builds up and causes stability requirements.

sparql is hard to implement
(1)sparql and sql map very well. The most of features and all common features of sparql have 100% mapping to sql
(2)sparql syntax parsing is not strictly necessary. sparql is just one of many serializations of rdf graph templates.
If there's an easier to parse serialization even if non-standard, it's very easy to map to sparql and sql for those who want it.

thus you can think of sparql as glorified or prettified sql depending on what subset of sparql you implement

(3) Xesam QL doesn't expose essential SQL functionality, namely JOINs

future-proofing the design, clean extensions vs hacks
hacks generally mean unintended or unnatural use of features, "stretching" of usage area. Usually this comes at a cost of:
flexibility
further extensibility

duplication of functionality across clients which should have been implmented once in the backend
(1) One stable and efficient vs a ton of buggy and slow imlementations. Also backend devs are more efficient at making
the required functionality than client devs
(2) Bandwidth&latency between storage and query parts of backend vs query and client. Fetching 1/2 of DB over dbus and doing data mining yourself is sloooow.
(3) Grep-like backends belong to a lower-level framework... like a library which would implement a reasonably powerful QL over such backends. Otherwise
you have to implement a part of this library in each xesam client application.

simple vs easy approach:
asm is simple, C is easy
or rather you can make something "simple" for developers but hard to users or reasonably hard for developers and "easy" for users.

xesam:Author linking up document authors, creators and senders from simple string with name case to complex sender address case. linking up

Desktop Search Hackfest/Design discussion - Revision history

dneary: Desktop Search Hackfest/Design Discussion moved to Desktop Search Hackfest/Design discussion: Capitalisation

generalantilles: Categorization

84.22.107.11 at 14:06, 19 September 2008

84.22.107.11: New page: Points: 95% use cases should be sufficient: find example: (1)usually you remember where a file is located, that's 95% of use cases however if you don't, you use recursive search too...