karlcow: "In general, your application takes responsibility for providing document content to Search Kit in the appropriate form, namely a CFString object. For local, on-disk files supported by the built-in text extractor plug-ins, Search Kit knows how to get content for you. The text extractor plug-ins work with RTF, XML, plaintext, and PDF files, as well as with Microsoft Word documents."
karlcow: "Each term in a Search Kit index has a unique ID and is associated with a list of document URL objects that point to the documents it appears in. Various functions let you convert between terms and IDs, determine which documents contain a term, get the number of times a term appears in a document, and so on. See Search Kit Reference for details."
karlcow: "Even for supported file types, you can have your application supply a document’s content to an index. When you do, Search Kit takes it instead of extracting the text itself. You might do this, for example, for an XML document when your application understands the semantics of the tagging."
karlcow: "Each term in a Search Kit index has a unique ID and is associated with a list of document URL objects that point to the documents it appears in. Various functions let you convert between terms and IDs, determine which documents contain a term, get the number of times a term appears in a document, and so on. See Search Kit Reference for details."
karlcow: "Even for supported file types, you can have your application supply a document’s content to an index. When you do, Search Kit takes it instead of extracting the text itself. You might do this, for example, for an XML document when your application understands the semantics of the tagging."
karlcow: Use of Uris with the following format data://2004/07/nnnnn
dajobe: by howard Katz
dajobe: full of libbys :)
danbri: From a quick look, seems interesting. I like the motivation: "...to reuse many of the useful and innovative features and metaphors the XML Query Working Group spent so many thousands of hours developing, while omitting the more complex parts of the XQuery specification that are specific to XML and not required in an RDF environment".
danbri: "The basic idea is to reuse some of the fruits of the tens of thousands of long hours and hard work the working group put into XQuery, arguably the W3C's most complex specification. In the end, RDF is far simpler than XML, and XsRQL is correspondingly far simpler than XQuery. It shamelessly steals, er, borrows, much of what's best about XQuery and ignores the rest."
dajobe: full of libbys :)
danbri: From a quick look, seems interesting. I like the motivation: "...to reuse many of the useful and innovative features and metaphors the XML Query Working Group spent so many thousands of hours developing, while omitting the more complex parts of the XQuery specification that are specific to XML and not required in an RDF environment".
danbri: "The basic idea is to reuse some of the fruits of the tens of thousands of long hours and hard work the working group put into XQuery, arguably the W3C's most complex specification. In the end, RDF is far simpler than XML, and XsRQL is correspondingly far simpler than XQuery. It shamelessly steals, er, borrows, much of what's best about XQuery and ignores the rest."
danbri: I'm interested in his 3rd point: "The ideal indexing structure for triples is a cross between b-trees and hash tables. Hash tables, with their constant time performance are desirable, but we need a b-tree like structure for queries where the arc label is a variable (i.e., to determine which arcs leave an object). "
danbri: " The solution to these two problems is to do our own on-disk storage. The proposed storage is to use an indexing structure that is a cross between b-trees and hash tables. More details soon."
danbri: I'll ask if he got this any more written down...
danbri: " The solution to these two problems is to do our own on-disk storage. The proposed storage is to use an indexing structure that is a cross between b-trees and hash tables. More details soon."
danbri: I'll ask if he got this any more written down...
Wack: Searchable using Spotlight in Mac OS X - Tiger
Wack: "Developers can build importers, so the metadata engine can understand their custom file formats and include those files in searches."
eaon: it's full content indexing and "metadata" indexing...
Wack: "Developers can build importers, so the metadata engine can understand their custom file formats and include those files in searches."
eaon: it's full content indexing and "metadata" indexing...
dajobe: see seth's slides from yesterday
Arnia: Only just got sent the URL, apologies