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

Ron Daniel wrote:
> 
> 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?)

Sorry, I don't understand the question.

> 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

I agree. In addition to Frank's remark, I could imagine an
representation like

http://.../foo.txt dc:date urn:iso:8601:2001-9

This leads to primitive data types, whose discussion I'd rather see
postponed.

> 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).

Oooops! Thanks!

> > 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.

In M&S RDF/XML, literals cannot be used as subjects.

> > 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.

I agree. Although a syntax like N-triple does not have intrinsic
limitations that prevent serializing Level 2 models.

> > 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.

My point is just this: if we are to handle the language attribute
somehow, I'd prefer finding a clean general way to a special-case fix.

Thanks for the comments!

Sergey

Received on Tuesday, 10 July 2001 17:13:06 UTC