I have a related question on the same property.  In earlier versions of the core spec, the creator and similar resources were defined to be of type 'Resource or Local Inline Resource'.  In the tidying up of that terminology, the definition is now type=Resource, with representation=either.  However, this is not quite the same: the new spec does not seem to permit a local resource, and requires the foaf resource to be gettable.  Was this a deliberate change, or accidental?  What are the implications of requiring the creator and related person attributes to be gettable resources?  For example, is it required that the 'same' person used in two different service providers must have the same URI?  What does the 'same' person mean?

Personally, I would strongly prefer that providers be allowed to return local resources for foaf:Person or similar resources, avoiding any requirement that such things are persistent gettable resources.

Nick.

[email protected] wrote: -----

To: [email protected]
From: James Conallen/Philadelphia/IBM@IBMUS
Sent by: [email protected]
Date: 07/30/2010 09:44AM
Subject: [oslc-core] common properties creator and contributor


Looking deep into the core common properties I have a concern around the definition for and dcterms:creator and dcterms:contributor. In our Jazz world we often just pass around a user URI and the creator property might look like this:

<dcterms:creator rdf:resource="https://martha:9443/jazz/users/admin1" />

If a client did a GET on this resource they would most likely get redirected to the user's HTML page on the jazz server, and not get a foaf:Person resource.

I think it is important that we allow non-foaf:Person ids, since IDS can be asssigned/managed by a non-OSLC application, and we'll want to preserve this value because it is referenced in lots of other non-OSLC things.

I'm pointing this out because as I read the definition (range) for creator and contributor is only has foaf:Person. I think we need to allow creator and contributor to be either foaf:Person, or anyURI.



<jim/>

jim conallen
[email protected]
Rational Software, IBM Software Group

_______________________________________________
Oslc-Core mailing list
[email protected]
http://open-services.net/mailman/listinfo/oslc-core_open-services.net



Reply via email to