W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

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

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).

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

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741 (does not work in Asia)

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:45 UTC