RE: Fwd: namespace versioning (Dublin Core) use case for DAWG?

> [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