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 Sunday, 4 March 2001 17:02:24 UTC