- From: Henry Story <henry.story@gmail.com>
- Date: Fri, 9 Jul 2010 08:54:59 +0200
- To: Reto Bachmann-Gmuer <reto.bachmann@trialox.org>
- Cc: Pat Hayes <phayes@ihmc.us>, Linked Data community <public-lod@w3.org>, Semantic Web <semantic-web@w3.org>
On 8 Jul 2010, at 22:06, Reto Bachmann-Gmuer wrote: > On Thu, Jul 8, 2010 at 7:21 PM, Pat Hayes <phayes@ihmc.us> wrote: > >> >> On Jul 7, 2010, at 11:31 AM, Reto Bachmann-Gmuer wrote: >> >> On Wed, Jul 7, 2010 at 1:57 PM, Toby Inkster <tai@g5n.co.uk> wrote: >> >>> Without knowing the definition of foaf:Person, it's difficult to >>> conclude that foaf:Person is not a property. However, even without >>> knowing the definition of a literal, it is easy to conclude that it is >>> not a suitable node to be used as a property, so in my opinion, it is >>> sensible to state that triples containing a literal as the predicate >>> have no meaning (even though I think they should be syntactically >>> allowed). There may be a confusion with different meanings of literals. I certainly think that it is difficult to justify pure string literals as predicates. But there are many other types of literals. If you allow for a relation between a string and the thing it refers to such as a log:reference datatype then it is clear that we use those all the time: <http://bblfish.net/#hjs> "http://xmlns.com/foaf/0.1/name"^^log:reference "Henry" . I agree with Pat in that case, that it would just be easier not to put restrictions in the abstract rdf syntax at all, instead of complicating things all over the place. There are pragmatic reasons why sentences such as <http://bblfish.net/#hjs> "name" "Henry" . are not going to be successful, the main one being that it is impossible to adjudicate what the relation "name" refers to is about. >> >> I think it would be perfectly possible to have a datatype mapping to a >> value-space of properties. But I see no practical benefit with this so I'd >> prefer not to support literal predicates syntactically. >> >> >> I'd suggest, as a general principle, that one should ask: which is easier, >> to allow them or to prohibit them? There are costs both ways. Words like >> 'support' beg the question. >> > > Evaluating the revision of a standard many questions are around the > trade-off between stability and design elegance. The allegedly neutral terms > "allow" and "prohibit" seem to beg this question. > > Reto
Received on Friday, 9 July 2010 06:55:41 UTC