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

Re: thoughts and some refs about AFS-2 UC (simplicity, minimalism )

From: Alberto Reggiori <alberto@asemantics.com>
Date: Mon, 22 Mar 2004 15:46:43 +0100
Message-Id: <BC8593F6-7C0F-11D8-9378-0003939CA324@asemantics.com>
Cc: "ext Seaborne, Andy" <andy.seaborne@hp.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: Patrick Stickler <patrick.stickler@nokia.com>


On Mar 22, 2004, at 1:20 PM, Patrick Stickler wrote:

> On Mar 22, 2004, at 14:02, ext Seaborne, Andy wrote:
>
>>> (a) expressing queries and query results in RDF
>>
>> +1
>>
>> And I would add:
>>
>> () a standard means to make such a query (HTTP and/or SOAP) to a 
>> remote
>> datasource on the web.
>>
>> Not all situations need this protocol part or access (for example, a 
>> local
>> datasource may have other, more sophistaed means) but as a web
>> recommendation, the DAWG should include the web access aspect to meet 
>> the
>> charter.
>
> Agreed.

+1 for me too

and perhaps have the possibility to express more the one datasource in 
the same query from where to pull data/metadata  - also leaving to the 
implementation the decision how to merge or smush those graphs. Even 
though I understand this might kick back in provenance in our 
requirements....but assuming we ignore that aspect for the moment, I 
find the need to select RDF from several different datasources as 
crucial requirement for a "web query language".

>
> I think the DAWG rec could (perhaps should) in fact be two distinct
> documents, the first covering the expression of queries and query 
> results
> in RDF (i.e. the vocabulary and semantics), and the second covering
> protocol issues for clients submitting such queries to knowledge 
> stores.

agree - some work about recording query-results has been already done 
in the past, and recently nicely summarized

http://www.w3.org/2003/03/rdfqr-tests/summary.html

which also provides a little bit of guidelines how to run simple 
interoperability tests between tools/implementations

perhaps worth to add that page to the DAWG page for reference?

>
> We could even choose to have distinct "task forces" within the WG
> focusing specifically on each.

agree too - and I would expect that to happen at the first f2f meeting 
- or immediately after

>
>>
>>> (b) a standard definition of a concise bounded description of a 
>>> resource
>>> (c) a standardized means to request the concise bounded description 
>>> of a
>>>      specific resource
>>
>> The matter of "concise bounded description"s should be an orthogonal 
>> issue
>> to the general form of query and of protocol.  That is, it would be 
>> good if
>> it did not need to be distinguished in the rec.

I would rather agree with Andy here instead

> I don't agree.
>
> Unless you are intending to restrict query responses solely to
> bindings (which I think is both unnecessary and fails to meet
> the needs of a very broad range of use cases that we've already
> identified) you need to define what a "description" is.

I do not think so - I rather would find such a requirement quite 
restrictive

> I don't think it should be left up to each implementor to define
> themselves what they will consider a description (such as is the
> case with Joseki's 'fetch' operation) but that there should be
> consistency across implementations insofar as the default, normal
> behavior of DAWG conformant tools. Implementations may choose to
> offer other flavors of descriptions, fine, but we really do need
> to have a precise, standardized definition of a "concise bounded
> resource description".

even though that would be too much "application specific" - while we 
should try to be completely "opaque" on the "about" definition IMO

cheers

Alberto
Received on Monday, 22 March 2004 10:10:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:18 GMT