 |
 |
> > > > I think the assumption is that [URI -> resource] is actually a function > > > (with unknown and evolving domain). > > > > > > The domain is described. > > It's not defined for all URIs. You mean the function not it's domain? > > > > You're talking about a retrieval context. Think that makes things cumbersome > > (cp. http://www.w3.org/TR/rdf-concepts/#section-fragID) > > If I understand this correctly, it means the following: > > If we allow fragment identifiers in Dublin Core, we need to accept the > RDF definition of their semantics. If we do not accept the RDF > definition of their semantics, we risk incompatibility with RDF > applications. > > Thats interesting. > > Is this too subtle for the abstract model? I think this needs to be addressed. Applications will receive metadata in a variety of encodings. They should know, whether a fragment is intended as indicating an XML element or a thing in a world, which is denoted by a URIref. > > No, but again, the paper starts with "resources", not gadgets. So I > don't see where the paper becomes informal on that point. So let me be more specific: Is the use of "resource" in the paper the same as in RDF semantics? > > /Mikael > > -- > Plus ça change, plus c'est la même chose > The more things change, the more they stay the same > >