Re: [uf-discuss] xfn relationships of influence

[Tantek Celik]

Hi James,

I think you have some interesting ideas here and it would be useful to capture 
them in the xfn-brainstorming page.

Perhaps create a new (sub)section "influences and influencers" and add some of 
your thoughts starting with:

"The relationships I'm considering fall into two predicate groups, 
influence out(applied) and influence in(received)."

Thanks,

Tantek

-Original Message-
From: James Tindall <[EMAIL PROTECTED]>

Date: Fri, 29 Aug 2008 13:58:51 
To: Microformats Discuss
Subject: [uf-discuss] xfn relationships of influence 


I've been refering to the xfn-brainstorming wiki for guidance on 
additional xfn ralationships. I can see from the wiki page that there's 
a desire to find a word to define the inverse of 'follower' but what I 
need is to offer users more options to choose from on both sides of the 
relationship - specifically in relation to the flow of influence.

Are there any examples or points of reference out there that I may have 
missed that already extend the xfn relationship options in this 
direction? Or should I not even be thinking about doing such a thing 
because xfn is not about influence?

The relationships I'm considering fall into two predicate groups, 
influence out(applied) and influence in(received).

Influence out: 'follower', 'student', 'subscriber', 'listener', 
'reader', 'viewer', 'supporter' and 'collaborator'.

Influence in: 'inspiration', 'favourite', 'teacher', 'mentor', 
'adviser', 'influence', 'source' and  'collaborator'.

I'm interested to hear any thoughts on this - whether I'm reinventing 
some wheel - if I'm adding complexity where none is needed or any other 
suggestions?

cheers,

=James.Tindall
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] HTML5+RDFa discussion on WHATWG involves Microformats

[Manu Sporny]

Samuel Santos has started blogging about the HTML5 + RDFa/Microformats
discussion that we've been having in WHATWG:

http://www.samaxes.com/2008/08/29/the-semantic-web-and-rdfa/

-- manu

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] xfn relationships of influence

[James Tindall]

I've been refering to the xfn-brainstorming wiki for guidance on 
additional xfn ralationships. I can see from the wiki page that there's 
a desire to find a word to define the inverse of 'follower' but what I 
need is to offer users more options to choose from on both sides of the 
relationship - specifically in relation to the flow of influence.


Are there any examples or points of reference out there that I may have 
missed that already extend the xfn relationship options in this 
direction? Or should I not even be thinking about doing such a thing 
because xfn is not about influence?


The relationships I'm considering fall into two predicate groups, 
influence out(applied) and influence in(received).


Influence out: 'follower', 'student', 'subscriber', 'listener', 
'reader', 'viewer', 'supporter' and 'collaborator'.


Influence in: 'inspiration', 'favourite', 'teacher', 'mentor', 
'adviser', 'influence', 'source' and  'collaborator'.


I'm interested to hear any thoughts on this - whether I'm reinventing 
some wheel - if I'm adding complexity where none is needed or any other 
suggestions?


cheers,

=James.Tindall
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force

[Martin McEvoy]

Hello Manu, all

Manu I think you need to explain that RDFa is a way of expressing 
semantics in  html, not just a way of expressing  RDF annotations in html


Manu Sporny wrote:

Ben Ward wrote:
  

It will take a couple of weeks to give examples of how this will all
work, but I wanted to get feedback from this community before
proceeding. We have a fantastic opportunity in front of us now - who in
this community thinks that we should work with the W3C on this endeavor?
  

I'm not sure I completely see the benefit in this, and seeing your
examples would be very helpful in getting a better idea of what you're
proposing. 



I'll get a set of examples written up soon, then.

  

From your bullet points, it seems to suggest taking
microformat vocabularies and expressing them in RDFa, rather than HTML?
It seems redundant for publishers.


No, the markup would still happen in HTML, using Microformat properties,
but instead of using @class, we MAY (not MUST) use @typeof, @property,
and @content (in the case of machine-readable data) to express
Microformats.
  


Its interesting to point out that most people who publish Microformats, 
are not really expressing any semantics at all, @class doesn't expresses 
any semantics without meta data profiles and most publishers do not use 
them,  yes some search engines can pick up hcards and calendar events 
but really that's about it. any other Microformats are Ignored mostly.

The key being that these attributes are specifically designed to contain
semantic data. Here's a brief example showing how we could get rid of
the ABBR design problem by re-using RDFa's @content attribute. Note that
this would work in HTML 4.01, XHTML1.1 and XHTML2:


   Start Wearing Purple by
   Gogol Bordello
   May 14th, 2002

  
That is a good example of how microformats could be used in RDFa 
everything (to me) seems to be in the right place.


@typeof can include any root Microformat Class names
@property is any Microformat Property name
@rel is any microformat rel value

Microformats Map pretty well in this way

  

However, I do have a somewhat related issue that you might consider part
of this effort. Some discussions I've had lately revealed usefulness in
being able to _map_ microformats into RDF, for the purpose of combining
microformats with other RDF vocabularies in a back-end somewhere (so,
conversion for processing, rather than publishing. Publishing remains in
HTML where it is most effective).



Publishing would stay in HTML, where it is most effective. Nobody is
suggesting that it move elsewhere - RDFa follows the same principles as
Microformats in this case.

As for the mapping between uF/RDF Vocabularies, I started a page to do
just that back in October 2007:

http://wiki.digitalbazaar.com/en/Mapping-ufs-to-rdfa

Want me to move it to Microformats.org?
  


I think you should Manu, so the rest of the community can read your most 
excellent work :-)
  

I'm told that RDF ‘versions’ of vcard and icalendar are out of date
compared to the microformats. 



I don't think they are, but could be mistaken...

The last update to VCARD was on 22 February 2001:
http://www.w3.org/TR/vcard-rdf
and the vocabulary:
http://www.w3.org/2001/vcard-rdf/3.0#

The last update to iCalendar was on 29 September 2005
http://www.w3.org/TR/rdfcal/
and the vocabulary:
http://www.w3.org/2002/12/cal#

  

As such, it strikes me that rather than
maintaining duplicate specifications, it would instead make sense to
develop a set of standard transformations so that any microformat can be
transformed from HTML to RDF, without requiring duplicate effort to
maintain another spec. This I'm sure would relate closely to GRDDL,
since that already deals with transformation.



Yes, agreed, that would be useful.
  

Agreed.
  

Note, I'm talking about mapping rules, not separate specs. For example,
we have the ‘jCard’ page on the wiki, which I still feel should be more
generic ‘JSON Mapping Rules’ page that can cover parsing from any
format, not just hcard. 



We're also working on that in our company, but internally for now. There
is the issue of a generic object representation format for semantic data
objects. We have a generalized RDF-based representation for RDFa and
Microformats now... but didn't think this community would be interested
in such a solution. Should a wiki-page be started on various "JSON
Mapping Rules" between uF/RDFa to JSON?

-- manu
  


Best Wishes

Martin McEvoy

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
  


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hCard: Quick question about nicknames

[Michael Smethurst]

Hi Ciaran


On 29/8/08 12:30, "Ciaran McNulty" <[EMAIL PROTECTED]> wrote:

> On Fri, Aug 29, 2008 at 12:17 PM, Michael Smethurst
> <[EMAIL PROTECTED]> wrote:
>> For now I'm marking them all up with class="nickname". Is this stretching
>> the semantics of nickname too much?
>> 
>> Should I just be POSH and use class="pseudonym"?
> 
> Even if you use class="pseudonym" you still need to decide whether to
> populate N or NICKNAME.
> 
> What I mean is you either say George Eliot is given-name + family-name
> or a nickname, regardless of any extra POSH semantics you'd care to
> add.
> 
> The vCard RFC seems remarkably unenlightening about the semantics of
> the different fields:
> 
> " Type special note: The nickname is the descriptive name given instead
>of or in addition to the one belonging to a person, place, or thing.
>It can also be used to specify a familiar form of a proper name
>specified by the FN or N types.
> 
>Type example:
> 
> NICKNAME:Robbie
> 
> NICKNAME:Jim,Jimmie
> "
> 
> Based on the two examples I'd lean towards markup up pseudonyms that
> are structurally formatted like names as names, with everything else
> as nickname, i.e.:
> 
> George Eliot = given-name, family-name with a pseudonym wrapper
> El Greco = nickname

Don't have the pseudonym data at that granular a level

Family name, given name and additional names are given in addition so I'm
fn-ing those
> 
> However I don't think there's any hard-and-fast rule about it.
> 
> -Ciaran McNulty
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal 
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on 
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hCard: Quick question about nicknames

[Ciaran McNulty]

On Fri, Aug 29, 2008 at 12:17 PM, Michael Smethurst
<[EMAIL PROTECTED]> wrote:
> For now I'm marking them all up with class="nickname". Is this stretching
> the semantics of nickname too much?
>
> Should I just be POSH and use class="pseudonym"?

Even if you use class="pseudonym" you still need to decide whether to
populate N or NICKNAME.

What I mean is you either say George Eliot is given-name + family-name
or a nickname, regardless of any extra POSH semantics you'd care to
add.

The vCard RFC seems remarkably unenlightening about the semantics of
the different fields:

" Type special note: The nickname is the descriptive name given instead
   of or in addition to the one belonging to a person, place, or thing.
   It can also be used to specify a familiar form of a proper name
   specified by the FN or N types.

   Type example:

NICKNAME:Robbie

NICKNAME:Jim,Jimmie
"

Based on the two examples I'd lean towards markup up pseudonyms that
are structurally formatted like names as names, with everything else
as nickname, i.e.:

George Eliot = given-name, family-name with a pseudonym wrapper
El Greco = nickname

However I don't think there's any hard-and-fast rule about it.

-Ciaran McNulty
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Employment end dates in hResume - outstanding issue

[Ciaran McNulty]

As there's been some discussion about moving drafts into specification
status lately, I'd like to address one of the outstanding issues in
hResume.

The problem that has arisen quite a few times, is that a lot of people
with a resume are currently employed and don't know what to provide as
the DTEND in their markup for their current job.  The problem is not
as apparent with educational events, as they tend to have a defined
end point even if it's in the future (PhD students may argue, mind
you).

The solutions in the wild tend to be either:

1. Set the DTEND to the date the resume was generated.
The problem with this approach is that if I save your resume and come
back and look at it in a year's time, I might think your employment
period ended on that date.

2. Set the DTEND to some far-future date.
This could be confusing and could be taken to indicate that your
contract ends at some specified date in the future.

3. Set the DTEND to the same as DTSTART.
This makes the event be either instantaneous or 1 day long in
hCalendar, which could be confusing.

4. Omit the DTEND.
This is actually equivalent to option 3 (see
http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html)

Personally I don't think this problem is going to be solvable within
hCalendar, and 'ongoing' events may be somewhat out of spec for that
particular format.  I would lean towards choosing one of the above
approaches and defining some optional additional semantic within
hResume that indicates that an experience event is 'ongoing'.

My particular preference would be to recommend option 4 and add a
@class="ongoing" that can be added to an event in hResume:



  Managing Director
  Example PLC
  2002
  to
  2005




  CEO
  Another PLC
  2005
  to
  Present


When viewed by an hCalendar parser, the second event would be
considered to be an all-day event occuring on 23rd Jan 2005.  An
hResume parser would however note the presence of @class="ongoing"
within the event and be able to

I'd welcome any feedback about:

A. Whether this is a problem that needs solving, or if there's an
obvious way of representing these events in hCalendar that we've all
missed.
B. Whether it needs to be solved by adding a concept of 'now' to
hCalendar or whether it needs to be solved in hResume as I've
suggested.
C. What people think of my example markup.

Thanks,

-Ciaran McNulty
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] hCard: Quick question about nicknames

[Michael Smethurst]

Hello

The data I'm working with has an optional pseudonym field on the people
table.

Some of the values in here look like nicknames (eg le cadet, le grand,
JC001):

http://bbc-hackday.dyndns.org:2840/people/44970

http://bbc-hackday.dyndns.org:2840/people/31944

http://bbc-hackday.dyndns.org:2840/people/45140

But others look more like proper pseudonyms:

http://bbc-hackday.dyndns.org:2840/people/1394

http://bbc-hackday.dyndns.org:2840/people/1381


For now I'm marking them all up with class="nickname". Is this stretching
the semantics of nickname too much?

Should I just be POSH and use class="pseudonym"?



http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal 
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on 
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hcard: additional additional names

[Martin McEvoy]

Michael Smethurst wrote:

On 21/8/08 18:41, "Martin McEvoy" <[EMAIL PROTECTED]> wrote:

  

Michael Smethurst wrote:


Hi Martin


On 14/8/08 15:48, "Martin McEvoy" <[EMAIL PROTECTED]> wrote:

  
*family-name-preposition*  is probably more accurate to what you are
  

trying to describe "von" in dutch simply means "of" or "from"


Oh I quoted wrong there I meant to say "van" in Dutch simply means "of"
or "from" my bad! ;-)

"von" still means "of"  or "from" but is also used to indicate
German/Austrian nobility similar to "de" in French.




, "O" as in
  

"O'Donnell",  in Irish  means  "descendant of" or  "grandson of" (in
Gaelic Ua),  Mc and Mac are again Irish meaning "son of",  and "Fitz" as
in "FitzGerald"  is an Irish hash of the french "fils de" which also
means "son of". What I am trying to say is any of these prefixes simply
mean "of" and shouldn't really be considered part of their family name
although they mostly are,  think "Van Gough" would you know who I meant
if  I just said "Gough"?

  


Family-name-preposition it is. You can see beethoven here:

http://bbc-hackday.dyndns.org:1895/people/16
  
  

Ahh Shame! the link doesn't work for me



My bad. Was on internal port. Try
http://bbc-hackday.dyndns.org:2840/people/16
  


Thank you Michael looks Great the vcard extracts nicely too

try: 
http://transformr.co.uk/hcard/http://bbc-hackday.dyndns.org:2840/people/16



Best Wishes

Martin McEvoy

I will try it later


Best Wishes

Martin McEvoy
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss




http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal 
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on 
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
  


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hcard: additional additional names

[Michael Smethurst]

On 21/8/08 18:41, "Martin McEvoy" <[EMAIL PROTECTED]> wrote:

> Michael Smethurst wrote:
>> Hi Martin
>> 
>> 
>> On 14/8/08 15:48, "Martin McEvoy" <[EMAIL PROTECTED]> wrote:
>> 
>>   
>> *family-name-preposition*  is probably more accurate to what you are
>>> trying to describe "von" in dutch simply means "of" or "from"
> Oh I quoted wrong there I meant to say "van" in Dutch simply means "of"
> or "from" my bad! ;-)
> 
> "von" still means "of"  or "from" but is also used to indicate
> German/Austrian nobility similar to "de" in French.
> 
> 
>> , "O" as in
>>> "O'Donnell",  in Irish  means  "descendant of" or  "grandson of" (in
>>> Gaelic Ua),  Mc and Mac are again Irish meaning "son of",  and "Fitz" as
>>> in "FitzGerald"  is an Irish hash of the french "fils de" which also
>>> means "son of". What I am trying to say is any of these prefixes simply
>>> mean "of" and shouldn't really be considered part of their family name
>>> although they mostly are,  think "Van Gough" would you know who I meant
>>> if  I just said "Gough"?
>>   
>> 
>> Family-name-preposition it is. You can see beethoven here:
>> 
>> http://bbc-hackday.dyndns.org:1895/people/16
>>   
> Ahh Shame! the link doesn't work for me

My bad. Was on internal port. Try
http://bbc-hackday.dyndns.org:2840/people/16
> 
> 
> I will try it later
> 
> 
> Best Wishes
> 
> Martin McEvoy
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal 
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on 
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hcard: born and died and flourished

[Michael Smethurst]

Hi Toby / all


On 21/8/08 14:49, "Toby A Inkster" <[EMAIL PROTECTED]> wrote:

>> And I've decided to use class="dday" for date of death and
>> class='flourished-start' and class='flourished-end' for flourished
>> dates
>> 
>> Where either date is circa I've included ca. in the span with bday,
>> dday,
>> flourished-start or flourished-end:
>> 
>> ca. 1575-ca. 1614
>> 
>> Does this look /feel right or am I missing something obvious? Is there
>> established POSH for death date and flourished dates?
> 
> I've previously recommended using 'dday' for date of death. DDAY is
> the name of the property in the draft vCard 4.0 spec, so it seems
> likely that any future extension of hCard that does include a date of
> death will name the property 'dday'.
> 
> 'dday' is already supported in Cognition  cognition/>.
> 
> I imagine that your use of 'ca.' in dates will cause problems for
> some parsers, which expect to find an ISO 8601 date these - it
> certainly breaks in Cognition. You may be able to improve parser
> behaviour by using value excerpting:
> 
> 
>ca.
>1575
> 

I've ended up with something similar:

ca.
1660
-
ca.
1732

Which can be seen here:

http://bbc-hackday.dyndns.org:2840/people/45284

For flourished dates I've gone with:

fl.
ca. 1418
-
ca. 1426

As here:

http://bbc-hackday.dyndns.org:2840/people/45105

Does this seem acceptable?

Again this is useful:

http://www.library.yale.edu/cataloging/music/pernames.htm#dates


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal 
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on 
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss