Re: How to state simple facts in RDF

Dan--

Your reply is interesting, because while I was focusing on the "set" vs. 
"property" alternatives, you seem to be focusing on the variants of how 
to represent the property values (I was more-or-less lumping all the 
property value variants together, and didn't really mean to refer 
specifically to using plain literals as property values).  A lot of the 
drafts I seem to be seeing from SWBP seem to be focusing on the former 
kinds of modeling (which you also find in database modeling practice), 
rather than the latter, whereas the latter (particularly the URI vs. 
datatype value choices) seem to be more distinctive to the Semantic Web. 
  Is there some draft in process that focuses on the value 
representation issue (and related issues like associated property names)?

Just to illustrate, this issue recalls part of an answer I gave a while 
ago to a comment on the Primer examples, to the effect that the examples 
too-often used literals rather than URI-identified resources as property 
values:

"Take a Zip code, for example.  Is it best modeled as:

* a URI like usps:01730 (with "usps" representing a prefix officially 
defined by the US Postal Service) as the value of a predicate like 
ex:postalCode?

* a typed literal like "01730"^^usps:zipcode as the value of the same 
predicate (in this case, the USPS is defining a datatype for Zipcodes)?

* the same typed literal, but as the value of a USPS-defined predicate 
usps:postalCode (or a corresponding internationally-defined datatype and 
predicate)?

* the original plain literal, but as the value of the USPS-defined 
predicate?"

And I could go on with other possibilities.  But is there some work 
going on to suggest answers to questions like these?

--Frank


Dan Brickley wrote:
> 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 15:19:58 UTC