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

RE: literals as resources / completion of ACTION 2001-07-06 (dependencies)

From: Ron Daniel <rdaniel@interwoven.com>
Date: Fri, 6 Jul 2001 11:58:54 -0700
To: "Sergey Melnik" <melnik@db.stanford.edu>, <fmanola@mitre.org>
Cc: "rdf core" <w3c-rdfcore-wg@w3.org>
Message-ID: <EMEKICCGFEKJFGKMFLEPOEPJCPAA.rdaniel@interwoven.com>
Sergey said:

> I agree with Frank that "out of scope" is a weak argument.

"Out of scope" may be weak technically, but it is a vital
procedural tool to keep a group pointed at meeting its
deliverables. The members of this group have agreed to be
bound by its charter, which specifically excludes certain
things. Asking if we are playing by the rules we agreed
to play by is not a weak argument, it is not a technical
argument at all.

I don't have a problem with people going off and working out
alternate proposals. If we weren't doing that we would not be
doing our job. But this is not the time to advance a proposal
that we mandate any special URIs for literal strings. That goes
way beyond what is in the 1.0 M&S.
It does not belong in a clarification of 1.0 unless there
is implementation experience showing it to be a problem, and
all the implementations I am aware of are quite happy with
saying that the object of a statement can be a string or
a URI.

But since we are discussing this anyway:

> I'd like to see whether the clarifications summarized
> below break something in M&S that is not already broken, or have
> subtle troubles that I failed to identify.

I see a couple of things right off:

> 4. There is a set called Literals = {"urn:data:literal:"} x Unicode*.

(are you assuming that that the literal string is also the second
component in the tuple which names the string?)

As I mentioned on the call, I really worry that homographs are
going to break this. As an example, if we have the string
"2001-9" in RDF like:
  <rdf:Description about="foo.txt">
    <dc:date>2000-9</dc:date>
    <x:arith_problem>2000-9</x:arith_problem>
  </rdf:Description>

and make up a URI like
  urn:data:literal:2001-9
how do we indicate that one instance of the literal is to be typed
as a date and another is to be typed as an expression that will
evaluate to an integer? We can't just have the obvious
  urn:data:literal:2001-9    rdf:type    foo:iso-8601

So, I don't think you can copy the string into the URI.


> 7. There is a subset of Triples set called Statements = Resources x
> Properties x Literals.

Not just literals. Statements would be Resources x Properties x
UNION(Literals, Resources).


> Impact on applications:
> ----------------------
> 
> Current RDF applications can be declared as RDF Level 1. Level 1 has
> restrictions wrt to valid models that can be processed. Since only
> Level 1 models can be serialized in M&S RDF/XML,

That may be true, but you have not shown it to be so.

> RDF applications Level 2 drop several restrictions of Level 1. In
> particular, literals may be used as subjects (and properties?). A more
> flexible syntax is needed to be able to serialize any subset of
> entities (Level 2 model).

I think that is great, but it is not the job in front of us right now.


> Since namespaces are explicit, resource ("urn:isbn:","0123456789") is
> different from ("urn:","isbn:0123456789"). See comment on syntax
> below.

Yes, something like this needs to be done, the handling of namespaces in
M&S 1.0 must be fixed.

> Impact on xml:lang:
> ------------------
> 
> xml:lang could be resolved either (1) by ignoring xml:lang found in the
> M&S
> syntax altogether or, (2) by generating URI prefixes like
> "urn:data:lang:en:" etc.  This would cause
> ("urn:data:literal:", "foo") != ("urn:data:lang:en:", "foo") !=
> ("urn:data:lang:fr:", "foo")
> However, APIs may provide access methods that ignore the differences.

This is exactly the kind of jiggery-pokery with URLs that I want
us to avoid. Yes, it is good to know that "lang:en:chat" !=
"lang:fr:chat". That is not enough, as I am trying to illustrate
with the homograph examples.

Ron
Received on Friday, 6 July 2001 15:00:43 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:38:07 EDT