USE CASE: FOAF for names

[kcoyle]

Creator: Karen Coyle

Problem statement

In my metadata I want to use FOAF for names. Some names will be able to use foaf:givenname + foaf:familyname, others will be less formatted so we'll use simply foaf:name. In my input form, I need to be able to control that my data will have either foaf:name or BOTH foaf:givenname and foaf:gamilyname. This pattern needs to be expressed in my profile.

Stakeholders

The main stakeholders are those creating the metadata, plus those downstream users who will receive the metadata.

Links

FOAF

Requirements

Profile must be able to express OR, AND and NOT

Comments

I'm envisioning this as being able to express INCLUDE and EXCLUDE for any given property. (This might also apply to entity descriptions.) So in my profile, I would conceptually have something like:

property: foaf:name
    exclude: foaf:givenname
    exclude: foaf:familyname
property: foaf:givenname
    exclude: foaf:name
    include: foaf:familyname
property: foaf:familyname
    exclude: foaf:name
    include: foaf:givenname

What this says is that if I have foaf:name I can NOT also have foaf:givenname nor foaf:familyname. If I have foaf:givenname then I MUST have foaf:familyname but must NOT have foaf:name. etc.

[marianamalta]

Here we have a logic relation between properties....kind of the same type of issue of Use Case #18

[analice1pt]

@marianamalta , yes, but these properties are equivalent properties that only come by because we are using data from several sources.

[kcoyle]

@analice1pt Not necessarily from several sources. One AP could say: use foaf:name if you aren't sure of first/last names, but use foaf:givenname/familyname if you are. They aren't equivalent, they are alternates that are allowed.

It could be because the data store has data from different sources and considers their uses of foaf valid. But the AP is working on DATA, and sourcing is not key to this use case. It's operating on a graph but not checking provenance.

[analice1pt]

@kcoyle, in my example, the data was coming from different sources, but your example and its flexibility make sense to me.
Regarding provenance, I agree we are not talking about checking provenance. However, in this special case that we have data from several different sources, I think it may be helpful to have a record on which data comes from which source and how it is encoded and related to the other data. In my mind that information comes in the application profile. Again, for me the AP is not meant for validation; it is meant for design.