Re: [ANN] Major update of Lexvo.org
Hi Bernard, On Wed, Jul 7, 2010 at 2:04 PM, Bernard Vatant bernard.vat...@mondeca.com wrote: Basically that's it. If this practice seems good from social and technical viewpoint it could be a good idea to document it in a more formal way and put it somewhare on the wiki. There has been a page set up on the wiki a while ago about this issue, sorry can't find now the page address and who set it up, and I can't access now to http://community.linkeddata.org/MediaWiki/ for some reasons. This looks like a really good and sensible social process and I'd support it being more public on the wiki. Also, if anyone has datasets that they feel they cannot maintain any more, please consider using the Talis Connected Commons Scheme. We will host any public domain linked data for free for ever (or at least for as long as Talis exists which is 40 years so far). This is really a no-hassle solution with no strings whatsoever, just the commitment that the data is in the public domain for everyone's reuse. We are also looking to automatically deposit such datasets with the internet archive in the future. Please have a look at http://www.talis.com/platform/cc/ for more information on this scheme. Ian Looking forward for the feedback Bernard 2010/7/5 Gerard de Melo gdem...@mpi-inf.mpg.de Hi everyone, We'd like to announce a major update of Lexvo.org [1], a site that brings information about languages, words, characters, and other human language- related entities to the LOD cloud. Lexvo.org adds a new perspective to the Web of Data by exposing how everything in our world is connected in terms of language, e.g. via words and names and their semantic relationships. Lexvo.org first went live in 2008 just in time for that year's ISWC. Recently, the site has undergone a major revamp, with plenty of help from Bernard Vatant, who has decided to redirect lingvoj.org's language URIs to the corresponding Lexvo.org ones. At this point, the site is no longer considered to be in beta testing, and we invite you to take a closer look. On the front page, you'll find links to examples that will allow you get a feel for the type of information being offered. We'd love to hear your comments. Best, Gerard [1] http://www.lexvo.org/ -- Gerard de Melodem...@mpi-inf.mpg.de Max Planck Institute for Informatics http://www.mpi-inf.mpg.de/~gdemelo/ -- Bernard Vatant Senior Consultant Vocabulary Data Engineering Tel: +33 (0) 971 488 459 Mail: bernard.vat...@mondeca.com Mondeca 3, cité Nollez 75018 Paris France Web: http://www.mondeca.com Blog: http://mondeca.wordpress.com
Re: Subjects as Literals
On Jul 6, 2010, at 4:02 PM, Nathan wrote: Pat Hayes wrote: However, before I lose any more of my SW friends, let me say at once that I am NOT arguing for this change to RDF. so after hundreds of emails, I have to ask - what (the hell) defines RDF? Well, the current specs do. And they include a lot more than the semantics. In particular, they include syntactic restrictions on what can be in what part of a triple, like no literals in the subject position. When I say that the RDF semantics works fine for a more general version, what I mean is only to reassure folk who know that it would be only an editorial matter to change the specs to allow more general forms for triples, but who worry (as many folk do) that such a change might break something basic in the RDF semantics, which is known to be a deep, subtle complicated thingie - to reassure them that this will not break the semantics, in fact. Of course, the 'rdf semantics' document would need some revision, since it gives for inference rules for RDFS which presume that the syntactic restrictions are in place, things like that. But these changes would actually simplify the way the document is written compared to its present form. I've read that 'The RDF Semantics as stated works fine with triples which have any kind of syntactic node in any position in any combination.' Do the 'RDF Semantics' define RDF? or do the serializations? The specs do, which include the RDF graph model as well as the RDF/XML serialization, both normative. simply - does RDF support literal subjects or not Right now, it does not. - I've read the aforementioned sentence to read 'RDF Semantics support literal subjects' or should I be reading 'RDF Semantics could support literal subjects' or 'does support literal subjects' or? Could support (with some work, but not too much) is closest to the mark. See above. Pat Just seeking a definitive bit of clarity on 1: what defines RDF, 2: what is *currently* supported in that definition. Preferably a serialization unspecific answer :) Best TIA, Nathan IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola(850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Re: Subjects as Literals
On Jul 6, 2010, at 9:23 PM, David Booth wrote: On Tue, 2010-07-06 at 20:45 +0200, Henry Story wrote: [ . . . ] foaf:knows a rdf:Property . Well we can dereference foaf:knows to find out what it means. This is the canonical way to find it's meaning, and is the initial procedure we should use to arbitrate between competing understandings of its meaning. Right. The document you get upon dereferencing -- the follow your nose document -- acts as a URI declaration.[1] 1. http://dbooth.org/2007/uri-decl/ Just to clarify, that is David's idea and his suggestion. It seems like a sensible idea, in many ways. It seems to reflect some current practice. But it is not part of the current RDF spec., and it is controversial. Pat -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic. IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola(850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Re: Subjects as Literals
On Jul 6, 2010, at 9:51 PM, Sampo Syreeni wrote: On 2010-07-05, Pat Hayes wrote: This objection strikes me as completely wrong-headed. Of course literals are machine processable. What precisely does Sampo as a plain literal mean to a computer? Do give me the fullest semantics you can. In RDF, it means the five-character string ess-ay-em-pee-oh, in that order. It does not mean anything else. This meaning is fixed by the RDF specification documents themselves. BTW, these are Unicode characters, so consult the Unicode documentation for more detail on what exactly is meant by a character (it is surprisingly complicated, and makes fascinating reading.) As in, is it the Finnish Sampo as in me, my neighbour, or what would be roughly translated as cornucopia in some languages? As you did not specify any language tag, the characters are presumed to be in the English (Latin) alphabet. Technically, the characters are all in unicode plane 0. You could of course just answer that it's just a literal, but then you'd be telling precisely the same thing I did: that sort of thing has only axiomatic semantics, lacking the real world denotation which is needed if we want to actually apply this stuff to something tangible. Not at all. Character strings may not be 'tangible', but they are real things in the world. Being tangible isn't a necessary condition for being real. The world comprises many things, probably more kinds of thing than any of us are capable of imagining at any given moment (the 'horatio principle': it is a mistake to want to exclude things from the universe of everyone else's discourse, or to presume that one's own ontological biases are going to be universally shared by others.) So what is it? As opposed to me as an OID (I don't think the URI namespace registration went through yet): 1.3.6.1.4.1.12798.1.2049 ? I mean, if your semweb killer app ordered that, the user should mostly receive a no-thanks for hairy mail prostitution. If they ordered the third kind of Sampo -- they should probably receive hard psychedelics instead. (And yes, I know this is rather concrete bound. I think it should be, too.) Well, nobody is suggesting allowing literals as predicates [...] Why? Is there a lesson to be learnt there? Only that the world in general probably isn't ready yet for this kind of generalized logic. It is being used by specialists and those who really need it, like the security agencies (who have been using it for several years now). But it is easy to give 'ridiculous' examples for any syntactic possibility. I can write apparent nonsense using nothing but URIs, but this is not an argument for disallowing URIs in RDF. In fact it could be. Whatever format you accept, you should be liberal with, but at the same time you should always have an unambiguous, safe, productive and well-documented interpretation for it all. This is WRONG. The type specifiers *completely* disambiguate the text in the body of the literal. A language signifier tacked onto a plain literal doesn't, as I just showed. Actually it does. The literal denotes the string, no more and no less. An integer annotation on a number just says it's a number And that ends the matter, right there. A number is a real thing in the world, it is the denotation of a numeral. It doesn't carry anything else. If you want to talk about numbers of zlotys, or numbers of centimeters, then you need ontologies of zlotys and centimeters (or, perhaps, new datatypes for these things.) , not what unit it perhaps carries; those are two completely different kinds of numbers, carrying different operational semantics. No, they are not different kinds of *numbers*. There is only one kind of number, AKA the natural numbers (Im ignoring reals, rationals, and complex numbers.) With literals, typing has come up but it hasn't been fully integrated with the rest of the RDF grammar; you can still say things like 'ten(integer) much-likes Sampo@fi' without any usual type system catching the error. LIteral types don't check 'errors' in RDF. (Though this one ought to be caught by any RDF parser, in fact.) This is a complicated issue in the design of RDF, one which absorbed a great deal of the WG's time. Its probably not relevant to go into this here; it has to do with keeping RDF monotonic. I can wax lyrical on this if you really want me to. I'd say that's pretty far from well defined semantics. Even in the simplest, axiomatic sense. The literal is then the primary culprit -- otherwise you and others have done a swell job in tightening it up. For plain literals, the meaning of the literal is the string itself, a unique string of characters. That I know too. Well then, isn't that unambiguous enough for you? With Schema derived or otherwise strictly derived types, the level of disambiguation can be the same as or even better
Re: RDF Extensibility
On Jul 7, 2010, at 6:57 AM, Toby Inkster wrote: On Tue, 6 Jul 2010 16:11:19 -0500 Pat Hayes pha...@ihmc.us wrote: The world doesn't have facts like that in it. Classes and properties are intellectual constructs, not the stuff of reality. Hell, if a particle can be a wave, then surely a class can be a property. Anyway, RDF doesn't make logical a priori rulings about these kind of metaphysical segregations. For example, xsd:Number is a class, a property and an individual in RDF. Indeed - but who has claimed that classes and properties are disjoint? Although they may well overlap in some cases, foaf:Person still isn't a property. Without knowing the definition of foaf:Person, it's difficult to conclude that foaf:Person is not a property. However, even without knowing the definition of a literal, it is easy to conclude that it is not a suitable node to be used as a property Well, thats what I thought too, until people started using them that way in CLIF/IKL. It is very dangerous to presume that one can see clearly, ahead of time, that a construct cannot be usefully be used by anybody else. And such triples do have a meaning, technically, since the RDF semantics gives them one, without indeed any modification *at all*. , so in my opinion, it is sensible to state that triples containing a literal as the predicate have no meaning (even though I think they should be syntactically allowed). I would veto this option. To do this would be a lot more work than not doing it; and it would greatly complicate the semantic specification, which would have to keep track of this 'meaninglessness'. One could have a situation, for example, in which A entails B entails C, A and C are perfectly fine, but B has been declared 'meaningless'. Should this inference be blocked? Should it be an error? Why are we even asking this question? Pat -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola(850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Re: RDF Extensibility
On Jul 7, 2010, at 11:31 AM, Reto Bachmann-Gmuer wrote: On Wed, Jul 7, 2010 at 1:57 PM, Toby Inkster t...@g5n.co.uk wrote: Without knowing the definition of foaf:Person, it's difficult to conclude that foaf:Person is not a property. However, even without knowing the definition of a literal, it is easy to conclude that it is not a suitable node to be used as a property, so in my opinion, it is sensible to state that triples containing a literal as the predicate have no meaning (even though I think they should be syntactically allowed). I think it would be perfectly possible to have a datatype mapping to a value-space of properties. But I see no practical benefit with this so I'd prefer not to support literal predicates syntactically. I'd suggest, as a general principle, that one should ask: which is easier, to allow them or to prohibit them? There are costs both ways. Words like 'support' beg the question. Pat Hayes Reto IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola(850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Re: RDF Extensibility
On Thu, 8 Jul 2010 12:16:06 -0500
Pat Hayes pha...@ihmc.us wrote:
I would veto this option. To do this would be a lot more work than
not doing it; and it would greatly complicate the semantic
specification, which would have to keep track of this
'meaninglessness'.
Why would tools need to keep track of the meaninglessness? True
meaning is only assigned to triples by their human consumers.
One could have a situation, for example, in which A entails B entails
C, A and C are perfectly fine, but B has been declared 'meaningless'.
Should this inference be blocked? Should it be an error?
No, and no. While B is meaningless in itself, C might not be.
Rules/entailments operate over symbols, not over meaning. It's
perfectly feasible that something meaningful might be discovered by
applying a set of rules to symbols that are meaningless.
An entailment that generates a meaningless statement is probably a
dodgy entailment, but that doesn't mean it should be considered an
error by the rules engine.
What could { #Alice 56.2^^xsd:decimal #Bob . } possibly mean?
If we assume the class of numbers and the class of relationships is
disjoint [1], then 56.2^^xsd:decimal cannot be a relationship. If the
triple doesn't contain a relationship between a subject and an object,
but Concepts says that all RDF triples do. So a triple with an
xsd:decimal predicate makes no sense according to Concepts.
So my point in saying that literals should be allowed as predicates but
considered meaningless is to reconcile an arguably desirable feature
(the simplicity of allowing any node type to occupy any position in a
triple/quad) with an inescapable fact (that a triple with a literal
for a predicate doesn't make any sense). The pragmatic solution is to
just say, they're allowed -- tools can operate on them as normal -- but
should have no meaning to humans.
In much the same way as { #Alice #xyzzy #Bob . } has no meaning
until we have additional information about #xyzzy.
I'll add that it has been mentioned that one could mint a datatype URI
for relationships (e.g. ^^rdf:relationship). As a datatype is
essentially a mapping from strings to things, this would allow for the
creation of literals that represent relationships. In this case, I'd
concede that a triple with one of these datatyped literals as a
predicate would be meaningful. However, this does seem to be a bit of
a pathological edge case.
--
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk
Re: RDF Extensibility
On Thu, Jul 8, 2010 at 7:21 PM, Pat Hayes pha...@ihmc.us wrote: On Jul 7, 2010, at 11:31 AM, Reto Bachmann-Gmuer wrote: On Wed, Jul 7, 2010 at 1:57 PM, Toby Inkster t...@g5n.co.uk wrote: Without knowing the definition of foaf:Person, it's difficult to conclude that foaf:Person is not a property. However, even without knowing the definition of a literal, it is easy to conclude that it is not a suitable node to be used as a property, so in my opinion, it is sensible to state that triples containing a literal as the predicate have no meaning (even though I think they should be syntactically allowed). I think it would be perfectly possible to have a datatype mapping to a value-space of properties. But I see no practical benefit with this so I'd prefer not to support literal predicates syntactically. I'd suggest, as a general principle, that one should ask: which is easier, to allow them or to prohibit them? There are costs both ways. Words like 'support' beg the question. Evaluating the revision of a standard many questions are around the trade-off between stability and design elegance. The allegedly neutral terms allow and prohibit seem to beg this question. Reto
Re: FYI: Blog on HTTP Link header and host-wide well-known URI-s, and Linked Data
On Wed, 7 Jul 2010 07:03:21 +0200
Ivan Herman i...@w3.org wrote:
http://www.w3.org/QA/2010/07/new_opportunities_for_linked_d.html
Not sure why my comment yesterday has still not shown up, but for the
benefit of these lists...
I've been supporting some of these technologies in my Perl modules
http://search.cpan.org/~tobyink/ for a few months now. For example,
my SPARQL Protocol client is able to auto-discover SPARQL endpoints
from resource URIs (including documents, FTP addresses, e-mail
addresses) using the discovery stack.
So you could just do something like:
$sparql = SELECT ?name
WHERE {
[] foaf:name ?name ;
foaf:mbox mailto:j...@example.com .
};
$query = RDF::Query::Client-new($sparql);
$results = $query-discover_execute('mailto:j...@example.com');
It would use the discovery techniques discussed in that blog article to
find a SPARQL endpoint relevant to the e-mail address, and then execute
the query on that endpoint.
--
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk
signature.asc
Description: PGP signature
Re: Capturing the discussion (RE: Subjects as Literals)
Sandro, all, I created the wikipage as you suggested. It is sketchy and certainly a bit biased towards my own opinion but I guess this will be improved as the document extends. Le 07/07/2010 05:01, Sandro Hawke a écrit : Would anyone be willing to try to capture the results of this thread in a page or two of consensus (neutral point-of-view) text that would explain the situation to at least a majority of the folks who've jumped in here with misunderstandings? To my reading, you (Michael) and Antoine are expressing that most clearly, if you'd be willing. Michael, feel free to modify my first input. It would be good, I think, to incorporate the ideas and perhaps the structure used at the workshop: http://www.w3.org/2001/sw/wiki/RDF_Core_Charter_2010#Literals_as_Subjects ... but probably do it on another wiki page, eg: http://www.w3.org/2001/sw/wiki/Literals_as_Subjects (which does not yet exist as I write this). We could think of this as a FAQ response, where the Questions are something like: Why can't I use Literals in the subject position in RDF? For me, the only answer I know to this question is: You can't use literals as subjects because the spec says so. It would be good to have the history of this restriction to know why it was put in the spec in the first place. When are you going to change this? Hmm, can we really answer that question when the community is still very divided on whether it should be changed at all? How can I work around this restriction? and maybe: What would anyone want to use literals as subjects? What would it mean to use a literal as a predicate? Hoping someone will feel inspired to tie this up with a nice bow, -- Sandro Regards, AZ
Re: RDF Extensibility
On Jul 8, 2010, at 2:28 PM, Toby Inkster wrote:
On Thu, 8 Jul 2010 12:16:06 -0500
Pat Hayes pha...@ihmc.us wrote:
I would veto this option. To do this would be a lot more work than
not doing it; and it would greatly complicate the semantic
specification, which would have to keep track of this
'meaninglessness'.
Why would tools need to keep track of the meaninglessness? True
meaning is only assigned to triples by their human consumers.
One could have a situation, for example, in which A entails B entails
C, A and C are perfectly fine, but B has been declared 'meaningless'.
Should this inference be blocked? Should it be an error?
No, and no. While B is meaningless in itself, C might not be.
Rules/entailments operate over symbols, not over meaning.
Not exactly. See below.
It's
perfectly feasible that something meaningful might be discovered by
applying a set of rules to symbols that are meaningless.
An entailment that generates a meaningless statement is probably a
dodgy entailment, but that doesn't mean it should be considered an
error by the rules engine.
Well, but now I have to put on my semantics-maven hat. That word
entailment has a particular meaning: A entails B when for every
legal interpretation I, if A has the value 'true' in I, then so does
B. That is, entailment is any inference that is guaranteed to preserve
truth. Now, if something is meaningless, then its not true. So the
inference of a meaningless B from a is *always* invalid (unless A is
never true, ie a contradiction - a possibility that we can leave aside
in this context.) So by declaring some syntactic forms to be required
to be meaningless, we have broken any inference chains which use those
forms: such chains can never be classed as entailments, even though
the entailment of C for A may be perfectly OK.
In fact, disallowing literals as subjects produces exactly this kind
of 'missing link' problem, where (what would be a) valid inference is
blocked because it would have to go through an intermediate form which
is disallowed. I know you do not propose to make these forms
syntactically illegal, but the problem arises just as sharply if you
override the natural model-theoretic rules by imposing an 'alien'
interpretative value on them. The machinery of logic is simple, but it
does have its own internal, um, logic, and it all kind of hangs
together, and it gets broken by putting unnatural restrictions on it.
What could { #Alice 56.2^^xsd:decimal #Bob . } possibly mean?
If we assume the class of numbers and the class of relationships is
disjoint [1]
But RDF does NOT make this assumption. Nor, IMO, should it. Anything
can be (more properly, can be interpreted to be) a relationship, in
the RDF model theory. This simplest-possible assumption has proven to
be extremely robust and extremely useful, and is used in the RDF and
OWL-Full and ISO Common Logic semantics. It is, I suggest, a mistake
to mess with it without a VERY good reason. Preserving old logical
constraints is one quite good reason, given the utility of preserving
legacy systems. Imposing it because one can't think of a reason not
to, is not a good reason.
, then 56.2^^xsd:decimal cannot be a relationship. If the
triple doesn't contain a relationship between a subject and an object,
but Concepts says that all RDF triples do. So a triple with an
xsd:decimal predicate makes no sense according to Concepts.
Sure it does, if you read the semantics properly. See above.
So my point in saying that literals should be allowed as predicates
but
considered meaningless is to reconcile an arguably desirable feature
(the simplicity of allowing any node type to occupy any position in a
triple/quad) with an inescapable fact (that a triple with a literal
for a predicate doesn't make any sense).
But they can make sense, and indeed they have use cases. Pretty far
out use cases, but uses nonetheless.
The pragmatic solution is to
just say, they're allowed -- tools can operate on them as normal --
but
should have no meaning to humans.
In much the same way as { #Alice #xyzzy #Bob . } has no meaning
until we have additional information about #xyzzy.
I'll add that it has been mentioned that one could mint a datatype URI
for relationships (e.g. ^^rdf:relationship). As a datatype is
essentially a mapping from strings to things, this would allow for the
creation of literals that represent relationships. In this case, I'd
concede that a triple with one of these datatyped literals as a
predicate would be meaningful. However, this does seem to be a bit of
a pathological edge case.
The RDF semantics has had this mapping since day one, its the
composition of the mapping called IEXT with an intepretation mapping.
Pat
--
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk
IHMC (850)434 8903 or
Re: RDF Aggregation Operators (Was: RDF Extensibility)
On Wed, 2010-07-07 at 14:43 -0400, Adrian Walker wrote: Hi Pat, You wrote... ..how do we know, given some RDF, what semantic extensions are appropriately to be used when interpreting it? That is a VERY good question. This is something that RDF2 could most usefully tackle,... A fairly widely held view -- though I'm sure not universal -- is that the URIs used in the graph should signal the intended semantic extensions. For example, if you use an OWL predicate, then the OWL semantics for that predicate are intended. This is described in PART 3: Determining Resource Identity of Resource Identity and Semantic Extensions: Making Sense of Ambiguity: http://dbooth.org/2010/ambiguity/#part3 HOWEVER, it is important to distinguish between the intent of the RDF statement author and what the RDF consumer chooses to do with the graph. It is critical that the RDF consumer be able to determine the intended semantics of the graph, i.e., to be able to know what entailments the RDF author intended. This is essence of successful communication. But this does *not* obligate the RDF consumer to actually *produce* all of those entailments. That is a choice that is entirely up to the RDF consumer and will vary by application. The question that you are asking has to do with the roles, responsibilities and expectations of the URI owner, RDF statement author and RDF consumer. I have proposed some standard guidelines in The URI Lifecycle in Semantic Web Architecture: http://dbooth.org/2009/lifecycle/ There was some discussion at the RDF Next Steps workshop about having the next RDF working group tackle this issue, but the prevailing view was that it should not. Personally, I think this was because the issue is not yet well enough understood in the semantic web community as a whole. More education and discussion are needed first. -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Efficient Data discovery and Sync Support - proposed method and Sindice implementation
Apologies for cross posting - Dear all So far semantic web search engines and semantic aggregation services have been inserting datasets by hand or have been based on random walk like crawls with no data completeness or freshness guarantees. After quite some work, we are happy to announce that Sindice is now supporting effective large scale data acquisition with *efficient syncing* capabilities based on already existing standards (a specific use of the sitemap protocol). For example if you publish 30 products using RDFa or whatever you want to use (microformats, 303s etc), by making sure you comply to the proposed method, Sindice will now guarantee you a) to crawl your dataset completely (might take some time since we do this politely) b) ..but only crawl you once and then get just the updated URLs on a daily bases! (so timely data update guarantee) So this is not Crawling anymore, but rather a live DB like connection between remote, diverse dataset all based on http. in our opinion this is a *very* important step forward for semantic web data aggregation infrastructures. The specification we support (and how to make sure you're being properly indexed) are published here (pretty simple stuff actually!) http://sindice.com/developers/publishing and results can be seen from websites which are already implementing these (you might be already doing that indeed without knowing..) http://sindice.com/search?q=domain:www.scribd.com+date:last_weekqt=term Why not make sure that your site can be effectively kept in sync today? As always we look forward for comments, suggestions and ideas on how to serve better your data needs (e.g. yes, we'll also support Openlink dataset sync proposal once the specs are finalized). Feel free to ask specific questions about this or any other Sindice related issue on our dev forum http://sindice.com/main/forum Giovanni, on behalf of the Sindice team http://sindice.com/main/about. Special credits for this to Tamas Benko and Robert Fuller. p.s. we're hiring
