W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2001

Literals as Resources (was RE: draft partitioning of the issues)

From: Ron Daniel <rdaniel@interwoven.com>
Date: Thu, 28 Jun 2001 09:22:35 -0700
To: "Brian McBride" <bwm@hplb.hpl.hp.com>, "Aaron Swartz" <me@aaronsw.com>
Cc: "rdf core" <w3c-rdfcore-wg@w3.org>
Message-ID: <EMEKICCGFEKJFGKMFLEPAEAOCPAA.rdaniel@interwoven.com>
Aaron Swartz started a thread by saying:

>rdfms-literals-as-resources and rdfms-literalsubjects:
>  A large body of implementation and user experience shows the 
>  need for these issues to be clarified. I think that there is
>  certainly room for clarification of this within the charter of
>  the Working Group.

and later he said:

>  I'm suggesting that we make Literals a subset of
>  Resources. [...]  I'd suggest something like:
> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
>          xmlns="http://rdf.example.org/#">
>  <rdf:Description rdf:about="data:text/plain;Chicago">
>    <startsWith>C</startsWith>
>  </rdf:Description>
> </rdf:RDF>
> <data:text/plain;Chicago> <http://rdf.example.org/#startsWith> 
> <data:text/plain;C> .

Since no-one else from the original M&S and Schema groups has
spoken up, I guess I will. 

My recollection is that we considered "strings", later called
"literals", as being clearly (although unfortunately) distinct
from Resources. That distinction is called out in the M&S
document in the part of section 2.1 Brian cited earlier:

>  The object of a statement (i.e., the property value) can
>  be another resource or it can be a literal; i.e., a
>  resource (specified by a URI) or a simple string or
>  other primitive datatype defined by XML.

While I would prefer that we have a way to make literals
the subject of statements, it seems completely clear that
such a feature is NOT part of the 1.0 M&S. Since we are
chartered to clear up misunderstandings, any changes we
make to the model need implementation experience as a
justification (such as the essentially universal lack
of support for aboutEachPrefix). All the RDF parsers
I am familiar with treat literals as distinct from strings.
None of them convert literals into data URLs. (However,
I have not made any sort of broad study of RDF parsers,
so perhaps someone else can comment?) I simply don't see
sufficient implementation experience to justify this kind
of change to the 1.0 M&S.

I would suggest that we should do two things to clarify the
M&S on this point. The first is to strengthen the section
in 2.1 that was cited above, so that it says something like:

    The object of a statement (i.e., the property value) must
    be a resource or a literal. Resources are specified by
    URIs(or URI references - this depends on how we resolve
    the whole mess around identifiers.) Literals are strings
    or other primitive datatypes, which may contain XML markup.
    For version 1 of the RDF Model and Syntax, the set of
    Resources is distinct from the set of Literals.

Second, we should go on to clarify the case of data: URLs, which
was not treated in the original M&S. For that clarification,
I suggest that implementations treat them as URLs, not as

But Aaron's suggestion that we convert literals into occurances
of data: URLs is CLEARLY a change to the model. I am not at all
convinced this is a real simplification. We already have an
incredible mess around URIs to clean up. I don't see adding
something like such an automagic conversion as any sort of
real simplification, I'm afraid it is just going to make things
worse. This is particularly the case since I don't see any
real evidence that the current model is in doubt (as opposed
to having a different model with different properties).

I am, of course, willing to abide by the rule of the majority
if the group decides such a change is in-scope. But before
this group spends its resources on this issue, postponing
other issues we must consider, may I request a straw poll
on the level of support?

Received on Thursday, 28 June 2001 12:24:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:49 UTC