W3C home > Mailing lists > Public > public-rdf-wg@w3.org > November 2012

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

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 12 Nov 2012 03:44:58 -0600
Cc: Dan Brickley <danbri@danbri.org>, RDF Working Group WG <public-rdf-wg@w3.org>
Message-Id: <8E1B4CF6-BFAE-4D47-A9AB-F5FA1BBCD519@ihmc.us>
To: Richard Cyganiak <richard@cyganiak.de>

On Nov 9, 2012, at 6:56 AM, Richard Cyganiak wrote:

> 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).

That is a constraint about prefLabel, not about mal/wellformedness of lists. 

> 
>> 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.

Is this in fact true? Can you document this claim? It doesnt seem to me to be at all obvious. *Inference* works just fine with fragmentary information about lists, for example. 

You have to remember that RDF only *describes* lists, it does not actually construct them. So systems that "expect" to find the RDF equivalent of LISP S-expressions are badly designed from the get-go. 

> 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.

It might be a problem IF this were a fact. I'm not yet persuaded that it is. 

> 
>>> 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.

Good luck with that.  Consider the following:

_:x rdf:first :a .
_:x rdf:first :b .
_:x rdf:rest rdf:nil .

Is this ill-formed? Or does it simply imply

:a owl:sameAs :b ?

Certainly, if :a and :b denote the same thing, than this RDF just describes a list with one element; what is wrong with that?

> 
>> 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.

What is supposed to be well-formed, the list or the RDF description of the list? The list described in Dan's example is perfectly well-formed. 

Pat


> 
>> 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.

How about software that (for example) extracts subgraphs of RDF graphs to perform inference, or respond to queries?

Pat

> 
>> 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
>> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Monday, 12 November 2012 09:45:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:52 GMT