RE: Objective 4.2 : Change "provenance" to "data management"

Despite this rewording (which does at least attempt a more concrete
definition of what we're talking about), I still think we should avoid
trying to put this stuff into the query language.

The only technology that I think we all really agree on is RDF and the
RDF data model. It strikes me as blatantly wrong to attempt a query
standard based on some other data model, and "RDF+some meta information"
is some other data model. If the meta information can be exposed in RDF,
then our query language should support it by default. If it can't be
exposed in RDF, then why are we considering native support in an RDF
query language?

My understanding is that the reification features of RDF were defined
explicitly to allow this kind of data. Trying to define a new meta-data
layer because this working group doesn't like what the RDF core group
came up with is exactly the kind of out-of-scope project we shouldn't be
engaging in. At best, we should raise issues against RDF core to point
out that their data model does not suffice for what we consider common
usage.

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org 
> [mailto:public-rdf-dawg-request@w3.org] On Behalf Of Seaborne, Andy
> Sent: Monday, July 19, 2004 12:06 PM
> To: 'RDF Data Access Working Group'
> Subject: Objective 4.2 : Change "provenance" to "data management"
> 
> 
> 
> The text in v1.123 is:
> """
> 4.2 Provenance
> It should be possible for query results to include source or 
> provenance
> information.
> """
> 
> At the face-to-face, I suggested that one practical, 
> restricted way we might
> view this was as data management.  It is not a complete solution to
> provenance but that requires a common approach in more than just this
> working group anyway.
> 
> Many RDF systems go beyond pure RDF and expose additional 
> information about
> where statements came from.  This has been found to be useful 
> in writing
> applications.
> 
> Suggested rewording to cover exposing just the data 
> management information
> that an RDF repository might have:
> 
> """
> 4.2. Support for RDF Aggregation Graphs
> 
> RDF can be used for data integration and aggregation where an 
> RDF repository
> is built by merging RDF triples from several other RDF 
> repositories or from
> non-RDF source converted to RDF.  Such an aggregation can be real or
> virtual.  
> 
> In such an RDF graph, the query client may wish to know where 
> the target
> server originally collected a triple or subgraph from.  The 
> query language
> and protocol should enable an RDF repository to expose such 
> information.
> """
> 
> This is a design objective, not a requirement.
> 
> It is supposed to be neutral as to whether we are talking 
> about quads or
> something based around log:includes style.
> 
> The merging of RDF graphs together is often called data 
> aggregation (c.f.
> RSS aggregators) so I used the term "aggregation graphs" to 
> differentiate it
> from aggregate query.  This is not union query - the 
> aggregate graph exists,
> and is not just for the purposes of a single query - but 
> exposing the nature
> of a union (if adopted) might be a consequence.
> 
> Would people whose system expose this sort of information say 
> what their
> experiences have been?
> 
> 	Andy
> 
>

Received on Monday, 19 July 2004 17:44:02 UTC