RE: Use/misuse of RDF:Value

Perhaps your note reveals a hint at where our disagreements and
misunderstandings are.  All of you examples are framed in terms of the
"agent elements".  In that case your argument makes some sense, e.g.,
the string "The Beatles" is the "human readable name" of that group.  My
statements, however, are meant to apply to all DC elements.  The methods
being discussed regarding default value are intended to be general.
Thus, the use of rdfs:label in the case of the subject element (picking
one example) seems pretty far from "a human readable version of a
resource name".  

While the agent problem is the most obvious poster child for the
so-called structured value dc problem, it is just one example.

Carl

> -----Original Message-----
> From: Aaron Swartz [mailto:aswartz@swartzfam.com]
> Sent: Sunday, March 04, 2001 5:03 PM
> To: lagoze@CS.Cornell.EDU; dc-architecture@jiscmail.ac.uk;
> www-rdf-interest@w3.org
> Subject: Re: Use/misuse of RDF:Value
> 
> 
> lagoze@cs.cornell.edu <lagoze@cs.cornell.edu> wrote:
> 
> > Comments inserted mid-text
> 
> Me too.
> 
> >>> 1. My reading of the rdf schema documentation says that 
> Stefan's suggestion
> >>> to use rdfs:label for the expression of a default value is very
> >>> conventional.  As stated in 5.2 of rdf schema, 
> rdfs:label: "This is used to
> >>> provide a human-readable version of a resource name".  
> The examples
> >>> throughout the document are multi-language labels for 
> definition, which
> >>> seems to have nothing to do with the purpose for which 
> Stephan is using it.
> >> I don't follow -- why is this so? It seems that the usage is
> >> just fine.
> > I'm willing to acknowledge being think, but I'm still at a 
> complete loss
> > to understand this use of rdfs:label.  HOw is an 
> "appropriate literal"
> > for a dc value at all related to the "human readable version of a
> > resource name" other than the fact that both are of type "string"?
> 
> What would you expect as an appropriate literal? In English 
> (and most other
> languages I know of) we identify resources by their names. 
> For example, the
> appropriate literal of the band with the URI 
> http://www.thebeatles.com/
> would be "The Beatles". Don't you think so? If not, what 
> would you choose as
> the literal.
> 
> >>> 3. Of special concern for the dc-architecture folks, I'm 
> still concerned
> >>> that the hanging of that arbitrary information off a 
> intermediate node
> >>> associated attached to a dc property says espresses that 
> the arbitrary
> >>> information is indeed a value of the dc property.
> >> I once again refer you to the argument in:
> >> 
> >> http://jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0102&L=dc-architect
> >> ure&P=27229
> > Your argument seems to rely on the notion of a "smart system".  As
> > others have pointed out in the previous emails, we've been pretty
> > focused in DC to make sure that dumb systems are able to 
> use a variety
> > of DC descriptions.  Mixing in arbitrary sub-graphs with dc 
> properties
> > esstentially gives no constraints and makes it difficult 
> for these dumb
> > systems.
> 
> And isn't the purpose of the dumb-down rules to allow dumb 
> systems to be at
> least somewhat smart?! Otherwise there's no purpose in 
> writing these rules
> at all and we can just throw the "dumb" Dublin Core systems 
> out the window!
> 
> >>> A property can have at most one range property. It is 
> possible for it to
> >>> have no range, in which case the class of the property value is
> >>> unconstrained. 
> >> Second, this is widely-believed to be a bug and is 
> expected to be soon
> >> changed.
> > Do you have any notion of what that soon is.  It makes me 
> uncomfortable
> > to propose a general usage that precedes the nature of a "bug fix".
> 
> From what I can see the group is a bit behind schedule, but 
> they're supposed
> to release this set of fixes on July 15. For what it's worth, 
> the co-editor
> of the spec and chair of the working group has said this is a 
> bug and he
> would change it if he could, but there are some procedural 
> matters to be
> taken care of. I think it is safe to rely on this fix, many 
> other published
> documents (both W3C and elsewhere) have.
> 
> >>> That is, I can't write a schema that says a dc property 
> can have a range
> >>> that is either a rdfs:literal or an intermediate node.
> >> Third, I believe that leaving the schema unconstrained 
> would have the same
> >> effect since an intermediate node is a resource and the 
> union of resources
> >> and literals covers (to my knowledge) all possible 
> properties in RDF.
> > Not comfortable with this.  The nice thing about constraints is that
> > they help us write programs that process the stuff.  If we formally
> > leave the nature of the rdf expression of dublin core, then why not
> > change the natural language description of all dc elements 
> to "anything
> > you really want to throw in this bucket".  John Kunze, in 
> response to
> > previous attempts to put complex values into dc elements 
> commented, "ok,
> > then give me a rule about what can't be the value of a dc element".
> 
> You've run into a problem/confusing part in RDF, which is 
> that intermediate
> resources are indistinguishable from any other type of 
> resource. I'm sorry,
> but that's how it is. No schema will change that.
> 
> -- 
> [ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]
>

Received on Monday, 5 March 2001 05:38:32 UTC