Talk:Rsfoaf

From RSS Extensions

Contents 1 Open questions 2 using URL constants in rel names and on targets as well 3 person should be a URL constant, not an element 4 one-way hash of IDs?

Open questions

1. Should the rsfoaf top-level element have attributes? E.g. the URL at which the file lives so anybody can download the file and know where to get an update from, if they want to?

using URL constants in rel names and on targets as well

I agree that having a specification for expressing relationships that is separate from the specification for expressing personal attributes (family name, starSign, favoriteDrink etc) would be useful.

It wasn't clear from your example in http://netmesh.info/jernst/Big_Picture/need-simpler-foaf.html what the semantics of the "rel" element were.

If someone were to have a full time job at company X and also do consulting as company Y, would they have two "rel" sections, both of form "business"?

jernst: As I hope the wiki explains now (does it?), what does and does not go into a particular section is entirely up to the person who defines the rsfoaf file. The idea is not to impose a structure here, just like RSS does not really define what constitutes a channel. But see below for more.

It would be useful to be able to subdivide 'business' links: someone using LinkedIn might have a large set of contacts of the category 'people who I worked with in a previous job' that should be able to separate from 'people who I work with now' or 'people who I've met at conferences'.

More generally, are the values of "name" attribute arbitrary human-readable strings, or are they tokens? Hopefully the latter, and if so it would seem useful for them to be from a more extensible namespace, e.g. have them be URL constants such as

jernst: nope, they are supposed to be strings assigned by the owner of the rsfoaf file according to whatever taste they have. Note that from a usability perspective, that's probably exactly what is expected. For example, in your average address book application, the user can create as many groups as they like, and would probably not accept the application if that wasn't the case.

<rel name="http://rsfoaf.org/relations#family">

That way other kinds of relationships such as those in http://www.perceive.net/schemas/20021119/relationship/ could be described without needing to update your FOAF relationship concept.

jernst: I completely agree with you that more interesting things can happen (in particular when computers start interpreting these files) once a shared ontology, or at least a discoverable ontology, is used. However, as I think it has become plenty clear, the world is not about to agree on any globally universal ontology on anything. (At least that's the conclusion that I have come to after about a dozen years of modeling, and meta-modeling, and ontology building). So: my idea here is that the notion of an ontology is optional, so people can do whatever they please as long as there is no universally accepted "best practice". For example, it could entirely be that the notion of an ontology is going to be eclipsed by some sort of tagging. I'd like rsfoaf to be able to live in both worlds.

jernst: what would you think if we created a "best practice" to allow child elements on rel that allow people to express those? Say, a concept tag with an href attribute that could point to a concept from an ontology, and a tag tag that could be used for tagging? By allowing N child elements, we could support multiple classification schemes/ontologies.

Also would it be possible to have the relationship kind also be an attribute on the link or similar elements, so that (1) rel elements could be omitted if not needed (e.g. I have only one connection) ...

"jernst: I'm against that. There's nothing wrong with a single child node in an XML file, and having that variation point makes parsers so much more complex and error-prone. (RSS had the same issue, I'd like to decide the same way)

and (2) a more specific kind of relationship could be indicated, e.g. amongst all the 'family' rel I might have one spouse, one parent and one child links. That way a user reading the document which does understand a specific kind of relationship (e.g. secret-societies.org/roles#lodge-leader) can display it properly, and those which don't can still put it into the appropriate grouping (personal/social not business).

jernst: one thing I was thinking about is a implies relationship between different rel elements. That way, for example, I could say, "The rel 'family' implies the rel 'acquaintance'". Would that address the issue?

--Markwahl 12:07, 14 Sep 2005 (PDT)

person should be a URL constant, not an element

It seems to me that 'person' as an element type is playing two roles simultaneously: (1) expressing a container suitable for having a URL attribute, and (2) providing the client reading this data with a 'hint' that the target of the URL is a person.

The concern I have with this is that it is likely users will want to extend (2) in order to express other kinds of targets for URLs

• family,e.g. "http://EXAMPLE-thesmiths.austin.tx.us"
• group,e.g. "http://EXAMPLE-sewingcircles.com#circle3"
• organization,e.g. "http://EXAMPLE-www.acm.org"
• socialNetwork,e.g. "http://EXAMPLE-www.linkedin.com/#me"
• pet,e.g. "http://EXAMPLE-spca.org/adopted/fido"

Have you considered using the 'A' element instead of the 'person' element, as in

<rsfoaf>
    <rel name="rsfoaf.org/relations#family">
      <a target="rsfoaf.org/targets#person"
         href="http://example.com/joe" title="Joe Smith"
         rel-name="rsfoaf.org/relations#father" />
    </rel>
    <rel name="pets.com/relations#pet">
      <a target="pets.com/targets#dog"
         href="http://spca.org/adopted/fido" title="Fido" />
    </rel>
</rsfoaf>

That way someone can express a new kind of relationship target such as '#dog' without needing to revise your FOAF spec. A client app which does not understand the target type of '#dog' will still be able to know that it is a link to a page about a friend that is not a person, even if it can't indicate to the user that the target of the link is a page describing a pet and not some other kind of non-person-entity.

--Markwahl 12:11, 14 Sep 2005 (PDT)

jernst: the question here is where to hard-code some sort of basic ontology (e.g. whether or not there is a person tag, or it's just a use of something more general as you suggest) or whether to make it completely generic. There are arguments that go both ways, as we probably all have seen them for decades in the arguments about strongly vs. weakly typed programming languages. Personally, I think there are only a few things that matter for the purpose of rsfoaf, such as:

• person
• organization
• role
• place
• thing

This might not be the exactly right list, but I'm sure you understand what I'm trying to say. For the <1% applications, one can always use XML extensibility.

jernst: However, you uncovered to an important issue: identity correlation. It might be that I know Joe has both this website, and that, or this e-mail address and that, but that Joe does not want the world to know, which is why he has more than one. In my very own rsfoaf file, I need to be able to express that I have a relationship to Joe, who is identified by more than one URL. I guess we should strike this up as a bug against my propopsal, and should probably use something like you suggest.

one-way hash of IDs?

FOAF has the concept of SHA-1 hash of the email address. This allows someone who has or knows the address to validate the connection, but does not give a stranger the ability to use that email address for Spamming.

Would you consider having a similar concept for links, such as allowing a hash of the id to be used, e.g.

 id-hash-salted-sha-1="ph5Mm5Pz8GgiULbPgzG37mj9poIuYYtrREwq"

This allows a user to express a FOAF relation to some ID URI without needing to reveal the URI (to spammers, scutters or other friends).

(This hash would be vulnerable to guessing: an attacker can validate whether or not the FOAF is a particular value, e.g.

http://www.whitehouse.gov/president/

but since the set of all possible URIs is quite large someone who is worried about this vulnerability could set up a HTML page anywhere on the internet with an arbitrary URI which simply redirects to an actual page.)

--Markwahl 12:18, 14 Sep 2005 (PDT)

jernst: I guess I have to confess I don't understand why this is necessary. The original reason for this hack (isn't it?) was that the FOAF folks wanted to use e-mail addresses to identify people, without spamming them at the same time. I have no problem saying that instead of using a mailto: URL, we could use a hashed e-mail address, but does this apply to all kinds of URLs (URIs?), or just to e-mail addresses.