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

On Mar 22, 2004, at 20:59, ext Rob Shearer wrote:

>
>
> I'm very skeptical of the "two document" approach to a single RDF query
> spec. It strikes me as an artifical link between two independent 
> issues.
> If we want to address both problems, let's let them stand independently
> and vote up or down on them independently.

Er. Isn't that one benefit of having two distinct documents? To be
able to consider each independently of the other.

>
> Analyzing a known collection of RDF triples is one problem. It's a core
> technology that is needed to work with RDF: one can imagine users
> querying local files or even use of the language purely 
> programmatically
> for internal data which fits the RDF model. The scope ranges from
> DOM/SAX to XPath to XQuery for XML.
>
> The architecture of the semantic web strikes me as *totally* different.
> Even if we did come up with a recommendation which addresses how to
> locate certain resources and the network protocol used to interface 
> with
> a remote query processor, implementing that would require an an ability
> to analyze the local RDF data.

I think most folks are thinking along fairly basic lines, such as
the HTTP bindings defined for the RDF Net API, with some tweaks
and adjustments -- and such an API is implementation agnostic,
merely defining a consistent interface for clients to use to
interact with known knowledge stores.

>
> What's more, heading down the architecture road strikes me as going way
> beyond the W3C's role here. The body's core competency is defining
> document formats, not architecture. If one were able to express a query
> in text form and get a text result, then I think all the other 
> standards
> take over from there; it's pretty hard to screw that up in SOAP. Where
> certain files should be stored, on which machines query services should
> be run, and who is allowed to access those services are precisely those
> issues that can't be standardized top-down. Different groups with
> different priorities and different approaches are going to try a lot of
> different architectures, and some will work better than others. We have
> nothing even close to the number of users needed to standardize on any
> particular architecture, and what users RDF has now are an extremely
> poor representation of the community we're hoping will emerge.

I personally think there are more than sufficient users to warrant
a basic, web-friendly pull-interface to web services. True, more
comprehensive solutions will likely emerge and some future WG may
take what we come up with several steps further, but that doesn't
mean we shouldn't take the first steps now.

>
> The community needs a sane schema for ins and outs before any
> significant applications can be built. Let's address that.

What do you mean by "schema for ins and outs"? An abstract API?

Patrick


>
>> -----Original Message-----
>> From: Kendall Clark [mailto:kendall@monkeyfist.com]
>> Sent: 22 March 2004 05:51
>> To: public-rdf-dawg@w3.org
>> Subject: Re: thoughts and some refs about AFS-2 UC
>> (simplicity, minimalism )
>>
>>
>>
>> On Mon, Mar 22, 2004 at 02:20:25PM +0200, Patrick Stickler wrote:
>>> 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.
>>>
>>> We could even choose to have distinct "task forces" within the WG
>>> focusing specifically on each.
>>
>> FWIW, I argued as much with some folks in Cannes. I think the query
>> and protocol parts of our task are entirely orthogonal (though there
>> is the one bit, in the protocol phase, of figuring out how to
>> represent query types...), and thus could be handled as separate DAWG
>> documents. (I know this is insanely early, but Query, Protocol, and
>> one or two Primers shapes up nicely as DAWG deliverables -- but, hey,
>> Dan, don't shoot me for talking about this too soon! :>)
>>
>> I took this position originally because I feared the query bit of our
>> work would turn into a death march. While I'm less skeptical about
>> that now, it still seems a smart choice to make, if necessary, to
>> separate the two issues as cleanly as possible.
>>
>> (Also, fwiw, I could do without provenance in the first version,
>> though I'd like to have a predicate in our capabilities vocabulary to
>> make assertions about provenance.)
>>
>> Kendall Clark
>> -- 
>> Sometimes it's appropriate, even patriotic, to be ashamed
>> of your country. -- James Howard Kunstler
>>
>>
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Tuesday, 23 March 2004 04:03:57 UTC