W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2005

RE: RDF version of IETF RFC metadata (and relationship to FOAF fi les? )

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
Message-ID: <PM-EH.20050110185019.DA6AC.1.1D@>

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 ;)


  <!-- 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>

  <!-- author's foaf file -->
    <foaf:name>N. Walsh</foaf:name>
      <foaf:Document rdf:about="http://www.ietf.org/rfc/rfc3120.txt">
         <rdfs:seeAlso rdf:resource="http://www.example.org/rdf/rfc3120.rdf" />

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: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:Document rdf:about="http://www.ietf.org/rfc/rfc3120.txt">
         <rdfs:seeAlso rdf:resource="http://www.example.org/rdf/rfc3120.rdf" />

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 Nowack

Kruppstr. 100
45145 Essen, Germany
Received on Monday, 10 January 2005 17:51:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:54 UTC