- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 13 Sep 2004 11:59:21 +0100
- To: "Eric Prud'hommeaux" <eric@w3.org>
- Cc: "DAWG public list" <public-rdf-dawg@w3.org>
> [Andy, I assumed some terminals here: "OR" for <OR> and <SC_OR> and > "=" for <EQ>. Are those right?] For value testing, boolean disjunction is "||" - "OR" is graph disjunction. Not that they have to be different tokens, they are separate at the moment for clarity. EQ is "==" is numercial equals. There isn't a "=" because it looks like assignment. Currently, (and its not nice) string equals is "EQ". If there is no testing with values that are strings but are tested as number [e.g. "2" < 3 ], the need for distinct string equals and numeric equals can go away. The query isn't quite syntactically correct: needs "." after the triples and before the "("'s but your syntax does work. Andy > 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 > } -------- Original Message -------- > From: Eric Prud'hommeaux <mailto:eric@w3.org> > Date: 10 September 2004 16:32 > > 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 Monday, 13 September 2004 11:06:16 UTC