RE: RDF and XLink

Hi Eve,

Some responses to your questions...


> -----Original Message-----
> From:	Eve L. Maler [SMTP:Eve.Maler@east.sun.com]
> Sent:	Thursday, May 18, 2000 8:50 AM
> To:	w3c-xml-linking-ig@w3.org; www-rdf-interest@w3.org
> Cc:	sergey Melnik; stefan Decker
> Subject:	RE: RDF and XLink
> 
> Ron, this is a fantastic effort; thanks.  
	[Ron Daniel]  Thanks, glad you liked it.

> I have some editorial comments 
> that I'll write up when I have some real time, but for now, here are some 
> reactions to the technical aspects:
> 
> - Do we need to cover linkbase lists (which have now shrunk down to a 
> special arcrole) explicitly?  Or will the mechanism for harvesting 
> statements out of arcroles suffice?
	[Ron Daniel]  I'll take this up in a separate message
	so as not to delay the rest of the responses any
	further.

> - In some cases, you've proposed XLink properties (xlink:label, 
> xlink:title, and so on).  Do we need a complete set for all XLink-related 
> semantics?  Can they be "virtual" (that is, without an actual resource
> that 
> can be retrieved), or do we need to supply some resource -- perhaps an 
> XLink RDF schema?
	[Ron Daniel]  I think they can be virtual, but what has
	to happen is that the XLink WG has to agree that the RDF
	concatenation hack is OK, and define the URI for the
	XLink namespace with a trailing '/' or '#' or '?'.
	Alternatively, define a second 'namespace URI' for use
	in the RDF harvesting that has that property. 
	In neither case is it mandatory that the URIs resolve
	to things, but in practice there should be at least a
	human-readable version of the spec there.

	Note also that I'm playing a little fast and loose with
	syntax, saying that the RDF meaning of xlink:title is
	a predicate that connects a resource and a label for
	the resource, but in XLinks there are syntactic constraints
	that also apply which RDF remains blissfully unaware of.
	That might argue for the second URI approach suggested
	above.


> - I'm not familiar with the RDF practice of constructing a predicate out
> of 
> an element type.  (I should read up on it, but need to catch a plane 
> soon...)  Is it "safe"?  E.g., if the element type is just an NCName, does
> 
> it still work?  Has this method been generally received well?
	[Ron Daniel]  One of the RDF abbreviations lets you
	treat nested element types as alternating predicate,
	type, predicate, type statements. It is received as well
	as any other part of the RDF syntax.

	(That's intended to be wry humor.)

	It will not work if there is no namespace URI
	associated with the element type.

	It would be safest not to do this, and always require an
	explicit arcrole. However, my intuition is that this
	will work in the vast majority of cases, where people
	want to harvest someone else's document that was not
	written with RDF in mind. Sounds like a 'may' to me,
	but not a MUST. Using arcroles is the 'must'. (My
	intuition, I must say, is something I try not to trust,
	so I'd really invite feedback from others on this point).
	 

> - I'm not sure it's a good idea to provide a description of how to 
> synthesize a canonical XPointer.  Can we get away with not doing this?  At
> 
> the least, I wouldn't want it to be a "must."  What is the "special 
> handling of title elements" relative to synthesizing XPointers?
> 
	[Ron Daniel]  We don't have to define a canonical means
	of synthesizing XPointers as long as we are OK that
	different implementations will harvest different RDF models
	from the same document. We just have to decide if that is
	a requirement or not. Obviously it would be at least
	'nice' for the models to be identical. But my customers
	are not going to slit their wrists (or mine) if this is a
	'may' or 'should' instead of a 'must'. (Hmmm, now that
	I think about it, a pretty high percentage of the ones
	that care about RDF would probably give me some grief
	about it. So I'd vote that it is at least a 'should'.)

	Special handling - I was assuming that we would want to
	form the XPointer so as to exclude any xml:title elements
	that were part of the content of the linking element.
	But we know what happens when we assume.  :-)


> - I think that the whole title element, not just its contents, should be 
> the object of an RDF statement.  There might be important attributes on
> the 
> element, such as xml:lang, that help you decide how to handle it.
	[Ron Daniel]  Yes, the xml:lang thing is a good point.
	So when the predicate is xlink:title, the object is
	an XML Literal like
	  <name xlink:type="title" xml:lang="en-US">Zing!</name>
	Is that what you are thinking?

> - I do think behavior attributes should be handled along with everything 
> else.  But why not associate them with the arc, instead of the ending 
> resource as you suggest?  They're a property of traversal, not of one 
> resource or the other.
[Ron Daniel]  Sorry for the murky nature of my prose. I
   suggested "hanging them off the
	   resource that is the reification of the traversal."
	which is an awkward way of saying that they should be
	associated with the arc. In RDF, to associate things
	with the arc, you have to give it an identity (reify it).
	That makes it into a resource about which you can then
	make assertions.

	So, it is certainly possible to deal with the behavior
	attributes. But it will be a little awkward because RDF
	does not specify an interoperable way of coming up with
	the URI for statements when reifying them. Before stepping
	into the tarpit of making up such an interoperable URI,
	I'd like to know there is some value associated with the
	effort. Frankly, I don't see it for the behavior attributes.
	The harvesting spec lets us build RDF models that have
	Property types like 'teacher', 'courseload', ... and
	Classes like 'Student' and 'Faculty'. In other words, they
	are derived from the document and express statements about
	the relations between resources. I can, somewhat, see how
	my company would care about those. The behavior attributes
	seem very different to me, and do not seem like things
	of value to my company, nor to most people interested in
	RDF.

	So, on this point I'm going to follow the maxim of
	"when in doubt, leave it out". I'll certainly put them
	in if someone can present a compelling argument on the
	need for them to be handled, and in an interoperable
	fashion.
	 
>  
> - If there's any reason at all to make the harvested statements a Set 
> instead of a Bag, we'd have to define a canonical harvesting order, yes?
	[Ron Daniel]  I assume you mean Seq, not Set?
	We would have to define a canonical order if we wanted
	models harvested by different implementations to be
	identical. (Although that constraint is the same whether
	a Bag or Seq is used. In both cases, the property types
	from the Bag (or Seq) node to the reified version of the
	harvested statements have the arc labels rdf:_1, rdf:_2,...
	Bag vs. Seq just states whether that order is considered
	important.

	This gets into another advanced topic, Contexts, that is
	periodically discussed but for which no standard exists.

	Ron

Received on Friday, 2 June 2000 15:17:59 UTC