In article <[EMAIL PROTECTED]>,
James Snell <[EMAIL PROTECTED]> wrote:
> Head elements in the entry have been discussed on the list and are
> described here: http://www.intertwingly.net/wiki/pie/PaceHeadInEntry.
> AFAIK, The proposal has been accepted and is slated for incorporation
> into the
I appreciate the interesting discussion although I do appologize for not
having sufficient
time to keep up with the thread. I think we all have some motion toward
a less constraining
Person construct with the ability to have more detail (phone number,
alternate e-mails,
or whatever). Having spe
At 7:38 AM -0800 1/4/05, Tim Bray wrote:
On Jan 4, 2005, at 1:39 AM, Henry Story wrote:
I was just looking closely at the atom:Person class [1] and found
some pretty arbitrary limitations:
- why should a Person only have one e-mail address?
- why should a Person only have one associated url?
I
--On January 4, 2005 7:38:27 AM -0800 Tim Bray <[EMAIL PROTECTED]> wrote:
> On Jan 4, 2005, at 1:39 AM, Henry Story wrote:
>>
>> I was just looking closely at the atom:Person class [1] and found some
>> pretty arbitrary limitations:
>> - why should a Person only have one e-mail address?
>> -
* Tim Bray <[EMAIL PROTECTED]> [2005-01-04 07:38-0800]
>
>
> On Jan 4, 2005, at 1:39 AM, Henry Story wrote:
>
> >
> >I was just looking closely at the atom:Person class [1] and found some
> >pretty arbitrary limitations:
> > - why should a Person only have one e-mail address?
> > - why shoul
On Jan 4, 2005, at 1:39 AM, Henry Story wrote:
I was just looking closely at the atom:Person class [1] and found some
pretty arbitrary limitations:
- why should a Person only have one e-mail address?
- why should a Person only have one associated url?
It does seem to me that this will make an
Oh. I should have mentioned how I see this being able to relate to
vcards. There is an rdf ontology for vcards on SchemaWeb [1]. It is a
little odd because it assigns names, addresses and other properties to
vcards instead of to people. But it would be easy to
add a property from a foaf:Person t
I think that the simplicity of atom:Person is fine. I have not checked
this out carefully, but it should be possible to map it quite easily to
foaf:Agent[1]. If one specified the following mappings:
- atom:Person is a subclass of foaf:Agent
- atom:uri is a super property of foaf:weblog
A while ago I wrote a Pace (but I can't seem to find it, maybe I didn't
finish
it, it was a while ago...) on using a vCard for the Person. vCards are
pretty
common and have some XML formats that would fit in to the current spec.
Any interest?
Brett Lindsley, Motorola Labs
Martin Duerst wrote:
I
I was asking myself the same questions when I was recently reading
the atom format spec.
Regards, Martin.
At 18:39 05/01/04, Henry Story wrote:
>
>I was just looking closely at the atom:Person class [1] and found some
>pretty arbitrary limitations:
> - why should a Person only have one e-mail
On 4/1/05 8:39 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:
> - why should a Person only have one associated url?
any objections to using atom:link here?
(other than generic objections to atom:link, that is)
e.
I was just looking closely at the atom:Person class [1] and found some
pretty arbitrary limitations:
- why should a Person only have one e-mail address?
- why should a Person only have one associated url?
It seems to me that one should follow the principle: only impose
limitations that are
12 matches
Mail list logo