- 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