[oslc-core] Questions about the creator property
ryman at ca.ibm.com
Thu May 6 14:31:41 EDT 2010
I think dc:creator should identify the user that created the resource. In
general, services will require a user to authenticate before they can
create resources (e.g. to prevent malicious use). The service will
therefore have some type of user identify available at resource creation
time, and in general that will be some type of resource. Therefore, a
simple string is not suitable. Using a foaf:Person provides a lot of
flexibility since it can have additional properties such user id's, names,
I think the simplest way to provide the user identity is via the
foaf:account property of foaf:Person, e.g. if I created a page on the OSLC
Here I am simply referring to the account resource. It could have type
foaf:OnlineAccount, but we don't have to inline that.
Arthur Ryman, PhD, DE
Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
Twitter | Facebook | YouTube
Dave <snoopdave at gmail.com>
Nick Edgar/Ottawa/IBM at IBMCA
oslc-core at open-services.net
05/06/2010 09:48 AM
Re: [oslc-core] Questions about the creator property
oslc-core-bounces at open-services.net
Thanks for the feedback. I think we may need some tweaks in this area.
I just added some text to the Core spec to clarify how foaf:Person is
supposed to be used:
- dc:creator MUST be either a Resource or Local Inline Resource of
- foaf:Person MUST include either a foaf:name or both foaf:givenName
That's is how things stand today. We only allow foaf:Person for
dc:creator and we only support those three foaf:Person properties. In
this area, OSLC Core was trying to approximate what was done in
earlier OSLC specs.
Of course, we still have time to change, and now is the time to get this
Seems like having some form of user ID would be a very good thing and
so I wonder:
1) Have we had user ID in previous OSLC specs and/or have we had some
discussions about the implications of specifying user ID's in
2) Any opinions about how we use dc:creator in OSLC? Should it be a
simple "full-name" string as the FOAF guidance suggests?
3) Any opinions about if or how we should specify user ID? I think
"foaf:OnlineAccount" would probably be preferable to "oslc:userID" and
preferable to pulling in the SIOC namespace.
On Wed, May 5, 2010 at 12:32 PM, Nick Edgar <Nick_Edgar at ca.ibm.com> wrote:
> Hi all,
> While working on the OSLC Automation provider prototype implementation
> RTC Build, some questions have come up over the exact representation to
> for the dc:creator property.
> The core spec says that the dc:creator is a foaf:Person, but later in
> Common Resource Definitions section it says "The Person resource can be
> as the value for a dc:creator or dc:contributor property. ", which is a
> Is it valid to use a simple string value instead of a foaf:Person?
> Having a foaf:Person value for a dc:creator property seems at odds with
> FOAF spec, where they suggest keeping dc:creator as the simple string
> using foaf:maker for the Person details, and that dc:creator is the same
> the maker's foaf:name.
> See http://xmlns.com/foaf/spec/#term_nick
> There are some good arguments for that approach in the linked
> The original problem that led to me reading up on this was whether and
> to include the Jazz user id (in addition to the real name). I
> thought of just tacking on a dc:identifier property inside the
> but foaf:nick is probably more appropriate, since the user id isn't a
> identifier for the actual person, and the scope of the user id isn't
> Could maybe use foaf:OnlineAccount instead, or in addition to
> but it's marked as 'unstable'; it would also be pretty verbose.
> Are there more specific recommendations for which of the foaf properties
> should be given? All the ones mentioned by the core spec (foaf:name,
> foaf:givenName and foaf:familyName) are listed as optional. Is it OK to
> just give foaf:name, or if one is given should they all be?
> Nick Edgar
> RTC Build component lead
> Oslc-Core mailing list
> Oslc-Core at open-services.net
Oslc-Core mailing list
Oslc-Core at open-services.net
More information about the Oslc-Core