- From: Benjamin Nowack <bnowack@appmosphere.com>
- Date: Mon, 10 Jan 2005 18:50:19 +0100
- To: "DuCharme, Bob (LNG-CHO)" <bob.ducharme@lexisnexis.com>
- Cc: www-rdf-interest@w3.org
On 10.01.2005 09:49:58, DuCharme, Bob (LNG-CHO) wrote: ... >I just tried this, > > <!-- main file --> > <rdf:Description rdf:about='http://www.ietf.org/rfc/rfc3120.txt'> > <title>A URN Namespace for XML.org.</title> > <creator>K. Best</creator> > <creator>N. Walsh</creator> > <date>2001-06</date> > <format>TXT</format> > <pr:byteCount>8068</pr:byteCount> > <rfc2026:status>INFORMATIONAL</rfc2026:status> > </rdf:Description> > > <!-- out-of-line-file --> > <rdf:Description rdf:about='http://www.ietf.org/rfc/rfc3120.txt'> > <creator rdf:parseType="Resource"> > <foaf:name>N. Walsh</foaf:name> > <foaf:page rdf:resource="http://norman.walsh.name/foaf"/> > </creator> > </rdf:Description> > ... >I just can't figure out how to show that the dc:creator "N. Walsh" has the >foaf file shown. I guess this is why RDF encourages the use of URLs in >objects, and I'll have to put something in my own namespace like >http://www.snee.com/ns/rfccreators#N.%20Walsh that can be created with an >automated mapping from the IETF creator value after all. It's not possible to "show that the dc:creator (string) 'N. Walsh' has a foaf file" in RDF(/XML) as it is not possible to serialize a triple with a subject which is a literal. To create URIs for the authors is possible but FOAFers usually discourage that practice. Another option would be to create an inverse functional (datatype) property to implement your use case, e.g. something like "ietfAuthor" which could be used in both the main and the out-of-line file. But the IETF author strings don't seem to be unambiguously identifying.. Maybe it's silly but having said that, I personally wouldn't worry about not being able to link the creator strings to foaf profiles but just try to model/provide the relationships and identifying information the other way round: Just provide RDF for the RFCs, encourage authors to link from their foaf file to your descriptions, and leave the issues to the implementors ;) e.g.: <!-- main file at http://www.example.org/rdf/rfc3120.rdf --> <rdf:Description rdf:about='http://www.ietf.org/rfc/rfc3120.txt'> <title>A URN Namespace for XML.org.</title> <creator>K. Best</creator> <creator>N. Walsh</creator> <date>2001-06</date> <format>TXT</format> <pr:byteCount>8068</pr:byteCount> <rfc2026:status>INFORMATIONAL</rfc2026:status> </rdf:Description> <!-- author's foaf file --> <foaf:Person> <foaf:name>N. Walsh</foaf:name> <foaf:made> <foaf:Document rdf:about="http://www.ietf.org/rfc/rfc3120.txt"> <rdfs:seeAlso rdf:resource="http://www.example.org/rdf/rfc3120.rdf" /> </foaf:Document> </foaf:made> </foaf:Person> It'd still be possible to create out-of-line files for known authors. Using FOAF's inverse functional properties, you could provide sufficient information to relate an author('s description) to the description of an RFC, e.g.: <!-- out-of-line file --> <foaf:Person> <foaf:name>N. Walsh</foaf:name> <rdfs:seeAlso rdf:resource="http://norman.walsh.name/foaf" /> <!-- at least one IFP, e.g. a weblog URL or mbox_sha1sum --> <foaf:weblog rdf:resource="http://norman.walsh.name/" /> <foaf:made> <foaf:Document rdf:about="http://www.ietf.org/rfc/rfc3120.txt"> <rdfs:seeAlso rdf:resource="http://www.example.org/rdf/rfc3120.rdf" /> </foaf:Document> </foaf:made> </foaf:Person> A triple store query would still return the redundant creator="foo" information for the RFCs but you'd also get the links between an RFC and its author's foaf data. And from an app/implementation point of view it should be possible to pragmatically map the creator strings to foaf descriptions with a similar foaf:name, assuming that the authors of a single RFC will almost always have different names. (heh, that looks a little bit like another use case for composite IFPs..) just some thoughts, sorry for the lengthy mail.., benjamin -- Benjamin Nowack Kruppstr. 100 45145 Essen, Germany http://www.bnode.org/
Received on Monday, 10 January 2005 17:51:04 UTC