W3C home > Mailing lists > Public > semantic-web@w3.org > July 2007

Re[2]: vCard confusion and RDF insufficiency

From: David Powell <djpowell@djpowell.net>
Date: Thu, 26 Jul 2007 19:45:30 +0100
Message-ID: <372076798.20070726194530@djpowell.net>
To: Garret Wilson <garret@globalmentor.com>
CC: Harry Halpin <hhalpin@ibiblio.org>, Semantic Web <semantic-web@w3.org>

Thursday, July 26, 2007, 6:04:46 PM, garret@globalmentor.com wrote:

> * For rdf:Seq, you can have multiple rdf:_3 properties, for example.
> * For rdf:Seq, you could have a rdf:_2809 property with no other
> properties, for example.
> * There is no way to specify the end of an rdf:Seq list.

Yeah, but equally you could say:

 * rdf:List can have a forked tails

 * rdf:List can have loops

 * rdf:List can have a missing nil terminator

All silly, but no sillier than someone adding multiple :_1's to a
givenName Seq.
>> The only objection would be the lack of closure of containers and lack
>> of formal semantics or ordering, but given that you cannot reasonably
>> put literals in rdf:List, I see no option other than use rdf:Seq.

> As pointed out by Sandro, you can indeed have literals in a rdf:List 
> (see http://www.w3.org/TR/rdf-schema/#ch_first ). It's just that it's a
> pain to place literals in a rdf:List using RDF+XML serialization.

> It seems fundamentally wrong to me to allow a particular serialization
> format of a general model to dictate the construction of an ontology.

Fair enough, I generally prefer rdf:List. If we aren't bothered about
tidy RDF/XML serialisation (and I'm not too bothered) then either a
List or a Seq of Literals is fine.

  (if you want RDF/XML with literal lists, you can always just do it,
  change the namespace, and provide a GRDDL to transform to the
  verbose RDF/XML syntax)

The OWL trick is interesting, but it scares me a bit (is it going to
be easy to SPARQL without inference?)

And using rdf:value just for the sake of RDF/XML does seem wrong for
the reasons that you stated above.

Received on Thursday, 26 July 2007 18:46:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:58 UTC