Re: Proposal to resolve ISSUE-102 (well-formed lists)

On 9 Nov 2012, at 11:57, Dan Brickley wrote:
>> 1. You believe that RDFS should avoid any kind of conformance statements, including RECOMMEND-level statements on the use RDFS terms.
> 
> I don't believe I said or suggested that. Rather, that the kind of
> conformance we've historically dealt with has been about the *meaning*
> of RDF/RDFS terms. If you don't use them in accord with their meaning,
> you can expect to pay the price of confusion and miscommunication; so
> if you don't want confusion and miscommunication you should stick to
> their official meaning.

Note that today, many new vocabularies contain explicit constraints. For example, a SKOS-using graph that contains two skos:prefLabels in the same language is considered inconsistent (although this is only expressed in prose, not in model theory).

> More in the concrete syntaxes / grammars have
> we talked about whether documents conform. I'm over generalising;
> 'conform' appears in http://www.w3.org/TR/rdf-mt/ in a few ways,
> ranging from structure of literals, to 'conformance to semantics'. The
> sense you're suggesting here seems more that we're introducing a
> notion of 'good' vs 'bad' graphs. Can that be made more explicit?

Systems that process rdf:Lists will generally expect to also find an rdf:rest if they find an rdf:first. If you give a graph that contains a non-well-formed list to another system, it's likely to cause problems, or not achieve whatever intent there was when the collections vocabulary was originally used. Therefore, authoring, inferring or otherwise producing such graphs is generally not useful. This fact isn't visible from the current set of specifications; in fact, Semantics goes to some length explaining that such graphs are allowed. That's a problem.

>> 2. You are concerned that the proposal is not phrased as actual literal spec text. Thus is does not yet spell out all the details that would enable you, as the editor of the spec, to assess whether the text is appropriate for the spec.
> 
> Well, since you're praising my vagueness, I'll praise yours. Details
> would help. But I think there's enough here to work with, since the
> general direction is clear. But yes, I would like to know whether you
> think the full rules can be written out,

I don't see a reason to believe that the full rules can't be written out.

> and how they interact with
> the various entailment regimes that might be in play.
> 
> (excuse the notation)
> 
> #foo subPropertyOf rdf:next .
> #x foo #y .
> #a a owl:InverseFunctionalProperty .
> #x #a #bar .
> #y #a #bar .
> 
> would such a graph violate the SHOULD, for concrete example?

s/rdf:next/rdf:rest/

Yes, this violates the SHOULD, because it uses rdf:rest, but not in a well-formed list.

> The intent here, if I got example right, is that x and y are indicated
> by common inverse functional property to be names for the self-same
> entity, introducing a loop into the 'next' link, which itself is
> mildly complicated by subproperty. Doubtless logicians can cook up
> more fiendish examples.
> 
>> 3. You believe that “graph containing no malformed lists” is a more useful concept than “graph consisting only of one well-formed list”.
> 
> Either would be fine. It was an illustrative example, suggesting a way
> of couching SHOULD-speak in more RDF-flavoured declarative terms.
> Whenever we see SHOULD, we can ask, 'who should do what, when?'.

Straw man answer: The SHOULD applies to anybody who produces (by authoring, inference, or any other means) RDF graphs.

> That
> kind of language generally works well if talking about classes of
> software component, service or document. My sense here is that we're
> talking about classes of document/graph, and I'd prefer to clarify
> that and make it explicit before leaping in to the specifics.

Talking about classes of graph is difficult here. I agree that “well-formed list” is a class of graph. However, any well-formed list, by definition, contains subgraphs that are not well-formed lists, so stating the constraint as one on graphs wouldn't work particularly well.

Best,
Richard




> 
> cheers,
> 
> Dan
>

Received on Friday, 9 November 2012 12:56:59 UTC