Re: first and rdf:rest as functional property

Jeremy Carroll said the following on 03/23/2009 05:40 PM:
> I tend to Reto's point of view that interoperability concerns lean towards a conservative use of lists.
> (Although I feel very uncomfortable with that - trying to stick to the spirit of a rule that hasn't been well-formulated - it's soul-destroying - the secret policeman inside is so much more vicious than the one who is publicly accountable. In this case, we could end up with an incredibly minimalist view of a list, that obligates us, on their construction, to much more work than any recipient of rdf lists actually requires. Maybe RDF Core should have made stronger statements about lists: e.g.
>
> [[
> For an RDF Graph published in an RDF/XML document, the following SHOULD all hold:
> + For any blank node or uri node that is the subject of an rdf:type rdf:List triple, or the subject or object of an rdf:rest triple, or the subject of an rdf:first triple then
>    - it is rdf:nil, and not the subject of an rdf:first or rdf:rest triple
>   Or
>    - it is the subject of precisely one rdf:first triple
>    - it is the subject of precisely one rdf:rest triple 
> + there is no rdf:rest directed cycle 
> ]]
> (such graphs are necessarily finite)
> ).
>
>
> Also, I would suggest that lists, in practice, are syntactically functional - and that this isn't a semantic constraint and trying to express such a semantic constraint is an amusing indulgence, and not a practical utility. 
> I would also reiterate that two lists sharing a tail is not, in my mind, a violation of conservative use of lists, but something that one should expect.
I don't like the idea of tying limitations to the notion of document and
to a serialization format, I think we should be able to serialize any
valid graph (with the known limitations RDF/XML) without violating any
SHOULD-level requirement, this includes (sub)graphs not describing a
full list.

What I do think, is that if a specification defines a property, that
definition should convey the meaning of the property accurately enough
so that there is a high level of intersubjectivity in the interpretation
of statements using this property.

Pat Hayes said the following on 03/23/2009 04:05 PM:
>> while on the other hand we do not currently
>> have spec legitimation to draw the following conclusion:
>>
>> |_:666 rdf:first <ex:aaa> .
>> _:666 rdf:first <ex:bbb> .
>> _:666 rdf:rest rdf:nil .
>> =>
>> <ex:aaa> ||owl:sameAs <ex:bbb>|
>
> But there is nothing to stop you declaring that you will make this
> inference, and making it. You should not seek to find spec
> legitimation: no specification can determine all your ontological
> decisions. Bear in mind that we are here talking about an RDF
> _ontology_ of "lists", not about list data structures themselves.
Only if the functionality of the property is part of the meaning of the
property in the shared language in use the above conclusion follows the
premises. If I'm correctly asserting that the property is functional
then it would be an advantage to the community using the language if the
specification (of family of specifications) introducing the term would
make this assertions (or assertions from which it can be deducted), if
on the other hand there is a possible world in which an rdf:List has two
distinct rdf:first elements then an rdf:List isn't what I expect it to
be and I would like to learn what it really means and in this case a
semantic web application dealing with data from an arbitrary user of
language cannot draw the conclusion.

Cheers,
Reto

Received on Tuesday, 24 March 2009 19:41:02 UTC