Re: Pre-LC review of SPARQL 1.1 Service Description

(Replying just to the parts that need replies.)

On 1/24/2011 4:07 PM, Gregory Williams wrote:
> On Jan 21, 2011, at 11:48 AM, Lee Feigenbaum wrote:
>
>> == Structural ==
>>
>> The document currently presents the service description classes
>> before the instances which are before the properties. When I was
>> reading the document, I kept expecting to see the meanings of
>> classes in the context of a SPARQl service, and was surprised when
>> things like sd:Language and sd:Function were defined in the
>> abstract instead of in terms of what it meant for a service. Of
>> course, this was because those semantics are (properly!) attached
>> to the properties that relate a service to a language, function,
>> etc.
>>
>> Still, I found this to be a confusing way to read the document, and
>> I think it would be improved by presenting the properties first
>> (with appropriate internal links to the domain&  range classes).
>
> Done. Are you happy with the remaining order of classes and then
> instances?

Yup.

>> * Abstract - "SPARQL implementation/service" =>  "SPARQL service"
>
> Do you think "service" here stands in for both the protocol level
> *and* the implementation level details? I was using "service" to mean
> protocol things (e.g. default dataset), and "implementation" to mean
> features of the query engine (e.g. supported extension functions).

The slash just reads to be as a synonym. I see your distinction (though 
don't necessarily think it's that important) though. If you want to put 
it back in, that's fine with me, I'd just prefer "or" or "and" rather 
than a slash.

>> * 3.2.3 sd:Function - Since we're giving all existing functions
>> URIs, should we reference those as instances of sd:Function here?
>
> I don't know. I don't you'd ever really use them in a service
> description since if you're a conformant implementation it's assumed
> you implement them (and so there's no need to mention them in the
> SD). What do you think?

Agree, leave it as is.

>> * 3.2.4 sd:Aggregate - did we decide whether this should be
>> "aggregate operation" or "set function" or something else?
>
> I don't there's been a decision yet. Section 11.4 of the current
> Query editor's draft calls them set functions. I'd be interested in
> hearing if Steve or Andy has a preference on what these should be
> called in the SD.

OK.

>> * 3.2.4 sd:Aggregate - same question about defined instances as for
>> sd:Function
>
> Same "don't know" answer :)

OK, leave as is.

>> * 3.2.6 sd:EntailmentProfile - I'm sure I've missed this, but what
>> is an entailment profile? We need to either define it here or else
>> link to a definition elsewhere.
>
> Good catch. All of this was added early on based on discussion with
> (I think) Birte and Ivan. I would appreciate someone more familiar
> with the specifics of profiles providing an appropriate link and/or
> definition.

OK, let's send separate emails on this and what to call aggregates.

>> * 3.3.4 sd:DereferencesURIs - is dereference a standard term? if
>> so, we should link to it. does it only apply to HTTP(S) URIs? if
>> so, we should mention that.
>
> AWWW uses "dereference" in this way
> (http://www.w3.org/TR/webarch/#dereference-uri):
>
> "Agents may use a URI to access the referenced resource; this is
> called dereferencing the URI."
>
> What do you think of changing the sd:DereferencesURIs definition to:
>
> """ sd:DereferencesURIs, when used as the object of the<a
> href="#sd-feature">sd:feature</a>  property, indicates that a SPARQL
> service will access referenced resources used in a FROM or FROM NAMED
> clause and use the resulting RDF in the dataset during query
> evaluation. """
>
> I think this works better with the AWWW definition, but now the
> description doesn't mention dereferencing at all(!). Any thoughts on
> a better definition?

I don't mind using the word dereference, but just think we ought to 
reference AWWW then.

> I wouldn't think sd:DereferencesURIs applies only to HTTP(S) URIs.
> I'm rather afraid of trying to model which types of URIs an endpoint
> can dereference, though I imagine a lot of endpoints that will
> dereference an HTTP URI might not dereference ftp URIs.

This may be something that we just want to remain quiet about.

>> * 3.3.7 sd:EmptyGraphs - I think this needs more explanation or a
>> pointer to the appropriate place in SPARQL Update or something like
>> that. Otherwise, it's sort of confusing what it means.
>
> Agree. I'd prefer a link into the update doc, but not sure there's an
> appropriate section that really describes this. The relevant text is
> sprinkled throughout the various operation sections (CLEAR, CREATE,
> and DROP). Do you think I should add a description of the "empty
> graphs" situation in the SD doc, or is that something that should be
> more explicitly explained in the update doc?

It's sort of hard to explain wherever it is. But I think the discussion 
belongs in the update document, so maybe you can work with Alex and Paul 
to get a better explanation and anchor in the update document?

>> * 3.4.1 sd:url - is the range here an xsd:anyUri literal, or is it
>> a URI reference?

> I think we agreed that it's a URI reference. I'm not sure if there's
> a good way to indicate that with a range assertion.

What about a line of text like:

"The object of the sd:url property is a URI reference."

?

>> * 3.4.9 sd:supportedLanguage - I wonder if we need more rigor than
>> "that it implements"? I think it's probably OK as is.
>
> I'm on the fence about this, but the whole "language" concept is
> intentionally vague, so I'm not sure if there's a good way to expand
> on this that would make it any clearer. I'm open to suggestions.

I'm imagining something that talks about conformance, but I think we're 
better off leaving it intentionally vague.

>> * 3.4.16 sd:namedGraph - is this predicate used with sd:Dataset in
>> addition to sd:GraphCollection? The modeling here is not clear to
>> me as a reader of the document.
>
> Yes, since sd:Dataset is a subclass of sd:GraphCollection. Would
> making explicit mention of this subclass relationship in the
> description of sd:namedGraph help readability?

Yes.

>> Also, should we use an example.org function URI, rather than the
>> ldodds example?
>
> I'm ambivalent about this. The ldodds example was nice because I
> believe it had been implemented in several systems and was a
> real-world example, but the non-standard java: URI space certainly
> makes it strange and perhaps not suitable for a spec.

It implicitly blesses this URI for the function in question, and I don't 
think we want to be in the business of doing that. And java: makes me 
vaguely uncomfortable, so I'd rather change it.

>
> I've fleshed out the references with these being normative:
>
> RFC2119 Content Negotiation SPARQL 1.0 SPARQL 1.1 Query SPARQL 1.1
> Update SPARQL 1.1 Protocol
>
> And these as "Other" references:
>
> SPARQL 1.1 Federation Extensions SPARQL 1.1 Uniform HTTP Protocol
> voiD Unique URIs for Semantic Web Entailment Regimes Unique URIs for
> OWL 2 Profiles Unique URIs for File Formats
>
> Does that look right?

Looks OK to me.

>
>> * Do we need a "Conformance" section? What does it mean to conform
>> to the service description specification? My suggestion would be
>> that it means that the service description is accessed according to
>> Sec. 2 and that the RDF returns contains exactly one triple of the
>> form:
>>
>> service-uri a sd:Service .
>>
>> and that all other uses of the vocabulary defined in the
>> specification are used in accordance with the usage specified in
>> the document. Or something like that.
>
> I've drafted a new conformance section and added it to the document.

This looks good to me too, though i'd like another pair of eyes on it.

Lee

> thanks for the detailed review,
>
> .greg
>
>

Received on Tuesday, 25 January 2011 14:48:24 UTC