- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Fri, 10 Sep 2004 11:31:40 -0400
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: Tom Adams <tom@tucanatech.com>, DAWG public list <public-rdf-dawg@w3.org>
- Message-ID: <20040910153140.GA18103@w3.org>
On Mon, Sep 06, 2004 at 01:39:28PM +0100, Seaborne, Andy wrote: > > The UC requirements on disjunction allows this to be expressed. > > I am not in favour of special mechansim syntax for handling the special > case of alternative predicates if we have the requirement for general > disjunction. We could have special syntax to generate the same query - > personally, I don't see a need from this one case. Are there others? I used this case as a motivator for graph disjunction (as opposed to an earlier proposal for disjunction only over values in the object and maybe subject). ask (<http://example.com/annot1> rdf:type a:Annotation. <http://example.com/annot1> a:annotates ?annotates. <http://example.com/annot1> a:context ?context. ( <http://example.com/annot1> dc0:creator ?creator || <http://example.com/annot1> dc1:creator ?creator ) ?creator a:E-mail ?email. ?creator a:name ?name. <http://example.com/annot1> a:ceated ?created. ( <http://example.com/annot1> dc0:date ?date || <http://example.com/annot1> dc1:date ?date ) <http://example.com/annot1> a:body ?body. ?body http:Body ?bodyData. ?body http:ContentType ?contentType) collect (?annotation ?body) There followed discussion of whether DAWG-QL should be simpler and the querier should turn the disjunction into a matrix of conjunctive queries and ask them all. Some proposed words for the reqly: The working group's strawman query language has arbitrary graph disjunction. Annotea [and probably others, any names?] has used disjunction to express predicate alternatives ala: SELECT ?annotation ?body WHERE { <http://example.com/annot1> a:annotates ?annotates . { <http://example.com/annot1> dc0:creator ?creator OR <http://example.com/annot1> dc1:creator ?creator } { <http://example.com/annot1> dc0:date ?date OR <http://example.com/annot1> dc1:date ?date } <http://example.com/annot1> a:body ?body } Alternatively, this query could be expressed using variable predicates and constraints on them: SELECT ?annotation ?body WHERE { <http://example.com/annot1> a:annotates ?annotates . <http://example.com/annot1> ?cp ?creator (?cp = dc0:creator OR ?cp = dc1:creator) . <http://example.com/annot1> ?cd ?date (?cp = dc0:date OR ?cp = dc1:date) . <http://example.com/annot1> a:body ?body } [Andy, I assumed some terminals here: "OR" for <OR> and <SC_OR> and "=" for <EQ>. Are those right?] Do you have a preferred solution? Does it change the query model or is a different syntax to express the same graph? > DCMI have choosen to have completely different URIs for dc11:titile and > dc10:title which coudlbe because the defintion of title has been > improved in 1.1 making it different from title in 1.0. > > The "temporarily assume" is a query premise and is an update on the > query target so, if the taget is a shared resource, needs locking or > transaction or something to isolate the query. > > There can be many appraoches to versioning so I don't think we are > helping to supporting one approach and not others at this stage. > > Andy > > Tom Adams wrote: > > > > > From the comments list for our perusal. > > > > > > > >Begin forwarded message: > > > >>Resent-From: public-rdf-dawg-comments@w3.org > >>From: Dan Brickley <danbri@w3.org> > >>Date: 3 September 2004 1:35:02 PM > >>To: public-rdf-dawg-comments@w3.org > >>Cc: public-swbp-wg@w3.org > >>Subject: namespace versioning (Dublin Core) use case for DAWG? > >> > >> > >>(sent to DAWG feedback list, cc: Best Practices WG) > >> > >>Hi > >> > >>Apologies if this is already covered and I missed it. > >> > >>I'd like DAWG to consider a use case in which a client application wants > >>all the "Dublin Core titles and descriptions" of some object, eg. > >>Danbri's weblog(s), and doesn't care at all which concrete Dublin Core > >>namespace is used. > >> > >>ie. > >> http://purl.org/dc/elements/1.0/ > >> http://purl.org/dc/elements/1.1/ > >> > >>This is a practical issue w/ DC deployment. I'm ignoring for now the > >>additional mess around upper/lowercase. Assume that we see dc10:title > >>and dc11:title in data, that the semantics are pretty much the same but > >>that the schemas aren't explicitly/formally mapped using RDFS or OWL > >>constructs. > >> > >>A couple of approaches leap to mind: 'or'ing, vs. query-specific > >>assumptions, ie. allowing the query to say "Well, let's temporarily > >>assume that dc1:title is a subproperty of dc2:title and vice-versa, > >>...". > >> > >>Both approaches have their issues (eg. 'or'ing both dc:title and > >>dc:description in a larger query might be hairy), > >>but my sense is that there is a real problem when similar > >>namespaces where new URIs have been assigned > >>despite modest differences in meaning. If DAWG ends up deciding not to > >>create technology that soothes these issues, the Best Practices WG might > >>consider making reference to querying issues when it discusses best > >>practice for Vocabulary Management and versioning. > >> > >>cheers, > >> > >>Dan > >> > >>ps. Eric P, perhaps you could comment on how this is dealt with in > >>Annotea's treatment of Dublin Core 1.0 vs 1.1? Some words to that effect above. I made a use case out of that [1] (look for EP-4). Annotea translates the above query to a monolithic SQL query. While I did deal with general graph expression with disjunction, negation and optionals, I haven't implemented disjunctions and optionals in value constraints (waiting for a use case to test success). Thus, only the graph disjunction example above works in the SQL translator. Both should work in the internal unifier. [1] http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar/0083 -- -eric office: +81.466.49.1170 W3C, Keio Research Institute at SFC, Shonan Fujisawa Campus, Keio University, 5322 Endo, Fujisawa, Kanagawa 252-8520 JAPAN +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA cell: +1.857.222.5741 (does not work in Asia) (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.
Received on Friday, 10 September 2004 15:31:40 UTC