Re: How to state simple facts in RDF

Frank Manola wrote:

>
> I think Mike's comment identifies the key distinction here.  The
> original examples "this case is closed", "this company is bankrupt",
> and "this article is a draft", and Mike's examples "my car is red" and
> "this food tastes good", have in common that no property name is
> explicitly given (unless you count "is").  Using classes, as in
> rdf:type, attempts to preserve this "propertyless" syntax, although by
> using rdf:type as a sort of generic property.
>
> Generally speaking, you only have two choices here:  you can describe
> things has having certain properties and values, or you can describe
> things as being members of certain sets.  So you can say either
>
> ex:myCar ex:hasColor "red"  .
>
> or
>
> ex:myCar rdf:type ex:RedThings  .

To connect this up to other SWBP discussions, both
designs come with RDF syntax costs. Actually there's a 3rd
design,
ex:myCar ex:hasColor ex:the_color_red
and a 4th design,
ex:myCar ex:hasColour "red"^^xsd:string

The problem in RDF/XML with the plain literal valued
version is that xml:lang can inherit down and give
different versions of "red", eg. in an xml:lang="fr"
document, we'll have "red"(fr), in an xml:lang="jp"
doc, "red"(jp). Furthermore there is no way in the
RDFS/OWL definition to say that the lang tag on
property values of ex:hasColor carries no meaning.
This puts work onto consumers of the data, since they'll
need to make judgments on when to ignore lang tags
and rejig their RDF queries etc accordingly.

The other paths, using URI-named resources as values,
and using RDF datatyping, are both rather costly in
terms of the RDF/XML syntax. Big long URLs clutter
up the data and scare away users.

I've hopes that RDF/A in XHTML2 will address at least
this latter case, and allow ex:the_color_red to be
written, rather than having 
http://example.com/colors/values#the_color_red appear
all the way throughout the instance data. Same goes for
datatype URIs.

BTW this exact problem hits us in FOAF. For now, the
foaf:gender property takes RDF plain literal values, putting
cost and complexity onto consumers (RDF geeks) rather
than producers (often less RDFist) of the data.

I don't know how RDF/A treats xml:lang, haven't looked
yet...

Dan

Received on Wednesday, 29 June 2005 14:44:11 UTC