vCard RDF merge....

[Renato Iannella]

Hi all....I am a bit behind in the merge of the two RDF/vcard  
documents.....but have a few questions:

1 - do we need the "v" namespace prefixes (in all the formal Ontology  
Reference) for all the properties and classes? (since you can use any  
prefix you like....)

2 - There is a missing property: PRODID - the id of the vCard creator  
(ie a software product) ?

3 - vCard does not specify the longitude and latitude properties (only  
GEO) and we do ?

4 - We define mobileTel property but vCard calls this "cell" ?

5 - We define a mobileEmail and personalEmail and workEmail  
properties, but there is no such semantics in vCard?

6 - I am not clear on the unlabeledAdr, unlabeledEmail, and  
unlabeledTel properties we define? Are these to capture all the "old"  
types in vCard like bbs-tel, parcel-adr etc?
And, of course, we don't capture these as rdf properties in our  
ontology?

7 - How to do handle vCard's preferred type? Ie I prefer my workTel  
over my homeTel?

8 - I assume we don't  wish to support Bag, Seq, Alt anymore.....but  
just support rdf:list?



Cheers...  Renato Iannella
NICTA

[Toby Inkster-4]

On Tue, 2009-06-30 at 12:55 +1000, Renato Iannella wrote:

> 4 - We define mobileTel property but vCard calls this "cell" ?
>
> 5 - We define a mobileEmail and personalEmail and workEmail  
> properties, but there is no such semantics in vCard?
>
> 6 - I am not clear on the unlabeledAdr, unlabeledEmail, and  
> unlabeledTel properties we define? Are these to capture all the
> "old"  
> types in vCard like bbs-tel, parcel-adr etc?
> And, of course, we don't capture these as rdf properties in our  
> ontology?
>
> 7 - How to do handle vCard's preferred type? Ie I prefer my workTel  
> over my homeTel?

A while back I wrote a little RDF vocab that extended the 2006 vCard
vocab. It introduces a few extra terms which I thought were useful,
mostly taken from the vCard 4.0 drafts at the time. e.g. a "lang"
property to indicate languages spoken by the person represented.

One other thing it has though is a more vCard-like way of representing
telephone numbers, e-mail addresses, etc.

Instead of:

        _:me a v:VCard ;
             v:fn "Alice Smith" ;
             v:workTel <tel:[phone]> ;
             v:mobileTel <tel:[phone]> .

It uses:

 _:me a v:VCard ;
            v:fn "Alice Smith" ;
            v:tel [
                    a vx:Tel ;
                    rdf:value <tel:[phone]> ;
                    vx:usage "work" , "mobile"
                ] .

My primary motivation was to be able to represent the data in the hCard
microformat in a way more closely related to the type+value structure of
hCard communications devices.

It's not perfect (it breaks the "range" of the 2006 v:tel, v:email and
v:label properties; and vx:usage should probably take a non-literal
value) but perhaps some of the ideas there could be incorporated into
the merged RDF vCard. In particular it should address all of the points
above.

> 8 - I assume we don't  wish to support Bag, Seq, Alt anymore.....but
> just support rdf:list?

I don't know why we even would want to support rdf:List?

Rather than:

        <rdf:Description rdf:about="#me">
          <v:note>
            <rdf:Bag>
              <rdf:li>Foo</rdf:li>
              <rdf:li>Bar</rdf:li>
              <rdf:li>Baz</rdf:li>
            </rdf:Bag>
          </v:note>
        </rdf:Description>

Just use:

        <rdf:Description rdf:about="#me">
          <v:note>Foo</v:note>
          <v:note>Bar</v:note>
          <v:note>Baz</v:note>
        </rdf:Description>

rdf:List only becomes especially useful when you want to indicate that
the set of values for a property is a closed set. The only useful
application I can see for it in vCard is to represent the structured
name data - i.e. I might want to have an rdf:List of my middle names, so
that people know exactly how many there are (in my case, one) and in
what order.

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

[Renato Iannella]

On 30 Jun 2009, at 19:17, Toby Inkster wrote:

> One other thing it has though is a more vCard-like way of representing
> telephone numbers, e-mail addresses, etc.

> Instead of:
>
> _:me a v:VCard ;
>     v:fn "Alice Smith" ;
>     v:workTel <tel:[phone]> ;
>     v:mobileTel <tel:[phone]> .
>
> It uses:
>
>  _:me a v:VCard ;
>    v:fn "Alice Smith" ;
>    v:tel [
>    a vx:Tel ;
>    rdf:value <tel:[phone]> ;
>    vx:usage "work" , "mobile"
> ] .
>
> My primary motivation was to be able to represent the data in the  
> hCard
> microformat in a way more closely related to the type+value  
> structure of
> hCard communications devices.
>
> It's not perfect (it breaks the "range" of the 2006 v:tel, v:email and
> v:label properties; and vx:usage should probably take a non-literal
> value) but perhaps some of the ideas there could be incorporated into
> the merged RDF vCard. In particular it should address all of the  
> points
> above.

Yes, this the model we used for the W3C Note.
See the examples in section "3.3 Properties with Attributes" in <http://www.w3.org/TR/vcard-rdf 
 >

If we stick to this, what implications are there for the vCard  
Ontology <http://www.w3.org/2006/vcard/ns>


> rdf:List only becomes especially useful when you want to indicate that
> the set of values for a property is a closed set.

Good point.


Cheers...  Renato Iannella
NICTA

[Martin Hepp (UniBW)]

Hi,
Just to make sure: I understood there is consensus that the domain of vcard:adr should be expanded from vcard:vcard to anything that can reasonably have an address, e.g. persons, organizations, or locations. Am I right? I think we discussed that before, but I cannot find a reference.

BTW, the Yahoo SearchMonkey doc does not specify a domain for vcard:adr

http://developer.yahoo.com/searchmonkey/smguide/vcard-details.html#vcard-adr

Best
Martin

Toby Inkster wrote:

On Tue, 2009-06-30 at 12:55 +1000, Renato Iannella wrote:
  

4 - We define mobileTel property but vCard calls this "cell" ?

5 - We define a mobileEmail and personalEmail and workEmail  
properties, but there is no such semantics in vCard?

6 - I am not clear on the unlabeledAdr, unlabeledEmail, and  
unlabeledTel properties we define? Are these to capture all the
"old"  
types in vCard like bbs-tel, parcel-adr etc?
And, of course, we don't capture these as rdf properties in our  
ontology?

7 - How to do handle vCard's preferred type? Ie I prefer my workTel  
over my homeTel?
    

A while back I wrote a little RDF vocab that extended the 2006 vCard
vocab. It introduces a few extra terms which I thought were useful,
mostly taken from the vCard 4.0 drafts at the time. e.g. a "lang"
property to indicate languages spoken by the person represented.

One other thing it has though is a more vCard-like way of representing
telephone numbers, e-mail addresses, etc.

Instead of:

	_:me a v:VCard ;
	     v:fn "Alice Smith" ;
	     v:workTel <tel:[phone]> ;
	     v:mobileTel <tel:[phone]> .

It uses:

	_:me a v:VCard ;
	    v:fn "Alice Smith" ;
	    v:tel [
		    a vx:Tel ;
		    rdf:value <tel:[phone]> ;
		    vx:usage "work" , "mobile"
		] .

My primary motivation was to be able to represent the data in the hCard
microformat in a way more closely related to the type+value structure of
hCard communications devices.

It's not perfect (it breaks the "range" of the 2006 v:tel, v:email and
v:label properties; and vx:usage should probably take a non-literal
value) but perhaps some of the ideas there could be incorporated into
the merged RDF vCard. In particular it should address all of the points
above.

  

8 - I assume we don't  wish to support Bag, Seq, Alt anymore.....but 
just support rdf:list?
    

I don't know why we even would want to support rdf:List? 

Rather than:

	<rdf:Description rdf:about="#me">
	  <v:note>
	    <rdf:Bag>
	      <rdf:li>Foo</rdf:li>
	      <rdf:li>Bar</rdf:li>
	      <rdf:li>Baz</rdf:li>
	    </rdf:Bag>
	  </v:note>
	</rdf:Description>

Just use:

	<rdf:Description rdf:about="#me">
	  <v:note>Foo</v:note>
	  <v:note>Bar</v:note>
	  <v:note>Baz</v:note>
	</rdf:Description>

rdf:List only becomes especially useful when you want to indicate that
the set of values for a property is a closed set. The only useful
application I can see for it in vCard is to represent the structured
name data - i.e. I might want to have an rdf:List of my middle names, so
that people know exactly how many there are (in my case, one) and in
what order.

  

[martin_hepp.vcf]

---

begin:vcard
fn:Martin Hepp
n:Hepp;Martin
org:Bundeswehr University Munich;E-Business and Web Science Research Group
adr:;;Werner-Heisenberg-Web 39;Neubiberg;;D-85577;Germany
email;internet:mhepp@...
tel;work:[phone]
tel;pager:skype: mfhepp
url:http://www.heppnetz.de
version:2.1
end:vcard

---

[Harry Halpin]

On Tue, Jul 7, 2009 at 6:03 PM, Martin Hepp
(UniBW)<martin.hepp@...> wrote:
> Hi,
> Just to make sure: I understood there is consensus that the domain of
> vcard:adr should be expanded from vcard:vcard to anything that can
> reasonably have an address, e.g. persons, organizations, or locations. Am I
> right? I think we discussed that before, but I cannot find a reference.
>
> BTW, the Yahoo SearchMonkey doc does not specify a domain for vcard:adr
>
> http://developer.yahoo.com/searchmonkey/smguide/vcard-details.html#vcard-adr

Yes, that was the consensus. Hopefully later tonight or tomorrow I'll
try to get around to actually finishing all those actions!

> Best
> Martin
>
> Toby Inkster wrote:
>
> On Tue, 2009-06-30 at 12:55 +1000, Renato Iannella wrote:
>
>
> 4 - We define mobileTel property but vCard calls this "cell" ?
>
> 5 - We define a mobileEmail and personalEmail and workEmail
> properties, but there is no such semantics in vCard?
>
> 6 - I am not clear on the unlabeledAdr, unlabeledEmail, and
> unlabeledTel properties we define? Are these to capture all the
> "old"
> types in vCard like bbs-tel, parcel-adr etc?
> And, of course, we don't capture these as rdf properties in our
> ontology?
>
> 7 - How to do handle vCard's preferred type? Ie I prefer my workTel
> over my homeTel?
>
>
> A while back I wrote a little RDF vocab that extended the 2006 vCard
> vocab. It introduces a few extra terms which I thought were useful,
> mostly taken from the vCard 4.0 drafts at the time. e.g. a "lang"
> property to indicate languages spoken by the person represented.
>
> One other thing it has though is a more vCard-like way of representing
> telephone numbers, e-mail addresses, etc.
>
> Instead of:
>
> _:me a v:VCard ;
>     v:fn "Alice Smith" ;
>     v:workTel <tel:[phone]> ;
>     v:mobileTel <tel:[phone]> .
>
> It uses:
>
>  _:me a v:VCard ;
>    v:fn "Alice Smith" ;
>    v:tel [
>    a vx:Tel ;
>    rdf:value <tel:[phone]> ;
>    vx:usage "work" , "mobile"
> ] .
>
> My primary motivation was to be able to represent the data in the hCard
> microformat in a way more closely related to the type+value structure of
> hCard communications devices.
>
> It's not perfect (it breaks the "range" of the 2006 v:tel, v:email and
> v:label properties; and vx:usage should probably take a non-literal
> value) but perhaps some of the ideas there could be incorporated into
> the merged RDF vCard. In particular it should address all of the points
> above.
>
>
>
> 8 - I assume we don't  wish to support Bag, Seq, Alt anymore.....but
> just support rdf:list?
>
>
> I don't know why we even would want to support rdf:List?
>
> Rather than:
>
> <rdf:Description rdf:about="#me">
>  <v:note>
>    <rdf:Bag>
>      <rdf:li>Foo</rdf:li>
>      <rdf:li>Bar</rdf:li>
>      <rdf:li>Baz</rdf:li>
>    </rdf:Bag>
>  </v:note>
> </rdf:Description>
>
> Just use:
>
> <rdf:Description rdf:about="#me">
>  <v:note>Foo</v:note>
>  <v:note>Bar</v:note>
>  <v:note>Baz</v:note>
> </rdf:Description>
>
> rdf:List only becomes especially useful when you want to indicate that
> the set of values for a property is a closed set. The only useful
> application I can see for it in vCard is to represent the structured
> name data - i.e. I might want to have an rdf:List of my middle names, so
> that people know exactly how many there are (in my case, one) and in
> what order.
>
>
>
> --
> --------------------------------------------------------------
> martin hepp
> e-business & web science research group
> universitaet der bundeswehr muenchen
>
> e-mail:  mhepp@...
> phone:   [phone]
> fax:     [phone]
> www:     http://www.unibw.de/ebusiness/ (group)
>          http://www.heppnetz.de/ (personal)
> skype:   mfhepp
> twitter: mfhepp
>
> Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
> ========================================================================
>
> Webcast:
> http://www.heppnetz.de/projects/goodrelations/webcast/
>
> Talk at the Semantic Technology Conference 2009:
> "Semantic Web-based E-Commerce: The GoodRelations Ontology"
> http://tinyurl.com/semtech-hepp
>
> Tool for registering your business:
> http://www.ebusiness-unibw.org/tools/goodrelations-annotator/
>
> Overview article on Semantic Universe:
> http://tinyurl.com/goodrelations-universe
>
> Project page and resources for developers:
> http://purl.org/goodrelations/
>
> Tutorial materials:
> Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on
> Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey
>
> http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009
>
>
>
>

[Peter Mika-2]

>
> BTW, the Yahoo SearchMonkey doc does not specify a domain for vcard:adr
>
> http://developer.yahoo.com/searchmonkey/smguide/vcard-details.html#vcard-adr 
>

We just regenerated the original documentation ;)

Peter

>
> Best
> Martin
>
> Toby Inkster wrote:
>> On Tue, 2009-06-30 at 12:55 +1000, Renato Iannella wrote:
>>  
>>> 4 - We define mobileTel property but vCard calls this "cell" ?
>>>
>>> 5 - We define a mobileEmail and personalEmail and workEmail  
>>> properties, but there is no such semantics in vCard?
>>>
>>> 6 - I am not clear on the unlabeledAdr, unlabeledEmail, and  
>>> unlabeledTel properties we define? Are these to capture all the
>>> "old"  
>>> types in vCard like bbs-tel, parcel-adr etc?
>>> And, of course, we don't capture these as rdf properties in our  
>>> ontology?
>>>
>>> 7 - How to do handle vCard's preferred type? Ie I prefer my workTel  
>>> over my homeTel?
>>>    
>>
>> A while back I wrote a little RDF vocab that extended the 2006 vCard
>> vocab. It introduces a few extra terms which I thought were useful,
>> mostly taken from the vCard 4.0 drafts at the time. e.g. a "lang"
>> property to indicate languages spoken by the person represented.
>>
>> One other thing it has though is a more vCard-like way of representing
>> telephone numbers, e-mail addresses, etc.
>>
>> Instead of:
>>
>> _:me a v:VCard ;
>>     v:fn "Alice Smith" ;
>>     v:workTel <tel:[phone]> ;
>>     v:mobileTel <tel:[phone]> .
>>
>> It uses:
>>
>>  _:me a v:VCard ;
>>    v:fn "Alice Smith" ;
>>    v:tel [
>>    a vx:Tel ;
>>    rdf:value <tel:[phone]> ;
>>    vx:usage "work" , "mobile"
>> ] .
>>
>> My primary motivation was to be able to represent the data in the hCard
>> microformat in a way more closely related to the type+value structure of
>> hCard communications devices.
>>
>> It's not perfect (it breaks the "range" of the 2006 v:tel, v:email and
>> v:label properties; and vx:usage should probably take a non-literal
>> value) but perhaps some of the ideas there could be incorporated into
>> the merged RDF vCard. In particular it should address all of the points
>> above.
>>
>>  
>>> 8 - I assume we don't  wish to support Bag, Seq, Alt anymore.....but
>>> just support rdf:list?
>>>    
>>
>> I don't know why we even would want to support rdf:List?
>>
>> Rather than:
>>
>> <rdf:Description rdf:about="#me">
>>  <v:note>
>>    <rdf:Bag>
>>      <rdf:li>Foo</rdf:li>
>>      <rdf:li>Bar</rdf:li>
>>      <rdf:li>Baz</rdf:li>
>>    </rdf:Bag>
>>  </v:note>
>> </rdf:Description>
>>
>> Just use:
>>
>> <rdf:Description rdf:about="#me">
>>  <v:note>Foo</v:note>
>>  <v:note>Bar</v:note>
>>  <v:note>Baz</v:note>
>> </rdf:Description>
>>
>> rdf:List only becomes especially useful when you want to indicate that
>> the set of values for a property is a closed set. The only useful
>> application I can see for it in vCard is to represent the structured
>> name data - i.e. I might want to have an rdf:List of my middle names, so
>> that people know exactly how many there are (in my case, one) and in
>> what order.
>>
>>  
>
> --
> --------------------------------------------------------------
> martin hepp
> e-business & web science research group
> universitaet der bundeswehr muenchen
>
> e-mail:  mhepp@...
> phone:   [phone]
> fax:     [phone]
> www:     http://www.unibw.de/ebusiness/ (group)
>          http://www.heppnetz.de/ (personal)
> skype:   mfhepp
> twitter: mfhepp
>
> Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
> ========================================================================
>
> Webcast:
> http://www.heppnetz.de/projects/goodrelations/webcast/
>
> Talk at the Semantic Technology Conference 2009:
> "Semantic Web-based E-Commerce: The GoodRelations Ontology"
> http://tinyurl.com/semtech-hepp
>
> Tool for registering your business:
> http://www.ebusiness-unibw.org/tools/goodrelations-annotator/
>
> Overview article on Semantic Universe:
> http://tinyurl.com/goodrelations-universe
>
> Project page and resources for developers:
> http://purl.org/goodrelations/
>
> Tutorial materials:
> Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey
>
> http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009
>
>
>
>  

[Martin Hepp (UniBW)]

Hi Peter,


Peter Mika wrote:
>> BTW, the Yahoo SearchMonkey doc does not specify a domain for vcard:adr
>>
>> http://developer.yahoo.com/searchmonkey/smguide/vcard-details.html#vcard-adr 
>>
>
> We just regenerated the original documentation ;)
>
> Peter
>

Does this mean you support a wider set of classes as the domain for
vcard:adr? So the following is RDFa would be correct from Yahoo's
perspective?

<div typeof="gr:BusinessEntity" about="#company">
    <span property="gr:legalName" datatype="xsd:string">Electronics
Ltd.</span>
    <span property="rdfs:comment" datatype="xsd:string">Electronics Ltd.
was established in 1960 and is UK's largest manufacturer of TV sets.</span>
    <a rel="rdfs:seeAlso" href="http://www.electronics.com"/>
    <a rel="rdfs:seeAlso" href="http://www.electronics.com/shop/"/>
    <div rel="vcard:adr">
        <div typeof="vcard:Address" about="#address-office">
            <span property="vcard:street-address">Penny Lane 1233</span>
            <span property="vcard:locality">London</span>
            <span property="vcard:region">London City</span>
            <span property="vcard:postal-code">123 ABC</span>
            <span property="vcard:country-name">United Kingdom</span>
            <a rel="vcard:email" href="mailto:info@..."/>
            <a rel="vcard:tel" href="tel:[phone]"/>
            <a rel="vcard:url" href="http://www.electronics.com"/>
        </div>
    </div>
</div>

Martin

--------------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  mhepp@...
phone:   [phone]
fax:     [phone]
www:     http://www.unibw.de/ebusiness/ (group)
         http://www.heppnetz.de/ (personal)
skype:   mfhepp
twitter: mfhepp

Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
========================================================================

Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/

Talk at the Semantic Technology Conference 2009:
"Semantic Web-based E-Commerce: The GoodRelations Ontology"
http://tinyurl.com/semtech-hepp

Tool for registering your business:
http://www.ebusiness-unibw.org/tools/goodrelations-annotator/

Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe

Project page and resources for developers:
http://purl.org/goodrelations/

Tutorial materials:
Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey

http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009





[martin_hepp.vcf]

---

begin:vcard
fn:Martin Hepp
n:Hepp;Martin
org:Bundeswehr University Munich;E-Business and Web Science Research Group
adr:;;Werner-Heisenberg-Web 39;Neubiberg;;D-85577;Germany
email;internet:mhepp@...
tel;work:[phone]
tel;pager:skype: mfhepp
url:http://www.heppnetz.de
version:2.1
end:vcard

---

[Peter Mika-2]

Yes, I would use it like that and I would also argue that is natural
(which means people will come up with it anyway).

Cheers,
Peter

Martin Hepp (UniBW) wrote:

> Hi Peter,
>
>
> Peter Mika wrote:
>>> BTW, the Yahoo SearchMonkey doc does not specify a domain for vcard:adr
>>>
>>> http://developer.yahoo.com/searchmonkey/smguide/vcard-details.html#vcard-adr 
>>>
>>
>> We just regenerated the original documentation ;)
>>
>> Peter
>>
>
> Does this mean you support a wider set of classes as the domain for
> vcard:adr? So the following is RDFa would be correct from Yahoo's
> perspective?
>
> <div typeof="gr:BusinessEntity" about="#company">
>    <span property="gr:legalName" datatype="xsd:string">Electronics
> Ltd.</span>
>    <span property="rdfs:comment" datatype="xsd:string">Electronics
> Ltd. was established in 1960 and is UK's largest manufacturer of TV
> sets.</span>
>    <a rel="rdfs:seeAlso" href="http://www.electronics.com"/>
>    <a rel="rdfs:seeAlso" href="http://www.electronics.com/shop/"/>
>    <div rel="vcard:adr">
>        <div typeof="vcard:Address" about="#address-office">
>            <span property="vcard:street-address">Penny Lane 1233</span>
>            <span property="vcard:locality">London</span>
>            <span property="vcard:region">London City</span>
>            <span property="vcard:postal-code">123 ABC</span>
>            <span property="vcard:country-name">United Kingdom</span>
>            <a rel="vcard:email" href="mailto:info@..."/>
>            <a rel="vcard:tel" href="tel:[phone]"/>
>            <a rel="vcard:url" href="http://www.electronics.com"/>
>        </div>
>    </div>
> </div>
>
> Martin
>
> --------------------------------------------------------------
> martin hepp
> e-business & web science research group
> universitaet der bundeswehr muenchen
>
> e-mail:  mhepp@...
> phone:   [phone]
> fax:     [phone]
> www:     http://www.unibw.de/ebusiness/ (group)
>         http://www.heppnetz.de/ (personal)
> skype:   mfhepp twitter: mfhepp
>
> Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
> ========================================================================
>
> Webcast:
> http://www.heppnetz.de/projects/goodrelations/webcast/
>
> Talk at the Semantic Technology Conference 2009: "Semantic Web-based
> E-Commerce: The GoodRelations Ontology"
> http://tinyurl.com/semtech-hepp
>
> Tool for registering your business:
> http://www.ebusiness-unibw.org/tools/goodrelations-annotator/
>
> Overview article on Semantic Universe:
> http://tinyurl.com/goodrelations-universe
>
> Project page and resources for developers:
> http://purl.org/goodrelations/
>
> Tutorial materials:
> Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A
> Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo!
> SearchMonkey
>
> http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009
>
>
>
>

[Renato Iannella]

On 9 Jul 2009, at 00:45, Peter Mika wrote:

> Yes, I would use it like that and I would also argue that is natural
> (which means people will come up with it anyway).


Depends on how faithful we want to be towards vCard 3.0

It specifically separates "delivery" and "telecommunications" addresses.
(and is preserved in the emerging vCard 4.0 work)

But i'm not bothered to much....only those who are after advanced  
reasoning....but its just an address, right!


Cheers...  Renato Iannella
NICTA

[Renato Iannella]

Hi all......I want to complete the vCard/RDF update soon...

So the question remains....are we happy to use the rdf:value+type  
model (which is what the 2001 note uses)?

If so, does this mean that we remove the homeTel Property (etc) from  
the ontology?

Renato

On 30 Jun 2009, at 19:17, Toby Inkster wrote:

> Instead of:
>
> _:me a v:VCard ;
>     v:fn "Alice Smith" ;
>     v:workTel <tel:[phone]> ;
>     v:mobileTel <tel:[phone]> .
>
> It uses:
>
>  _:me a v:VCard ;
>    v:fn "Alice Smith" ;
>    v:tel [
>    a vx:Tel ;
>    rdf:value <tel:[phone]> ;
>    vx:usage "work" , "mobile"
> ] .
>
> My primary motivation was to be able to represent the data in the  
> hCard
> microformat in a way more closely related to the type+value  
> structure of
> hCard communications devices.
>
> It's not perfect (it breaks the "range" of the 2006 v:tel, v:email and
> v:label properties; and vx:usage should probably take a non-literal
> value) but perhaps some of the ideas there could be incorporated into
> the merged RDF vCard. In particular it should address all of the  
> points
> above.

Cheers...  Renato Iannella
NICTA

[Martin Hepp (UniBW)]

I think this is more of a question for norman and harry.
I am inclined to define / keep subproperties of tel for homeTel,
mobileTel etc.
The current yahoo pattern attaches phone numbers directly to the
resource (without an additional node), see the example below.

also note that yahoo suggests using tel as a datatype property with the
pattern

           <span property="vcard:tel">[phone]</span>

while in th current 2006 ontology,  vcard:tel is defined as an object
property, so it should IMO be:

           <span rel="vcard:tel" href="tel:[phone]"/>

peter mika had quite some arguments for making phone number rather plain
strings than resources according to the respective rfc.

peter - would you share those publicly, please?

here is a pattern following the current yahoo recommendation:

<http://www.heppnetz.de/searchmonkey/company.html#business> a
gr:BusinessEntity, commerce:Business;
   rdfs:label "Hepp Space Ventures Inc."@en ;
   rdfs:seeAlso <http://www.heppnetz.de/>;
   vcard:adr <http://www.heppnetz.de/searchmonkey/company.html#address> ;
   vcard:fn "Hepp Space Ventures Inc."@en ;
   vcard:geo
       [ vcard:latitude "48.0802626"^^xsd:float ;
         vcard:longitude "11.6407428"^^xsd:float
       ] ;
   vcard:tel "[phone]"^^xsd:string ;
   vcard:url <http://www.heppnetz.de/> ;
   foaf:depiction <http://www.heppnetz.de/searchmonkey/logo.png> .


<http://www.heppnetz.de/searchmonkey/company.html#address> a vcard:Address ;
   vcard:country-name "Germany"@en ;
   vcard:locality "Neubiberg"@en ;
   vcard:postal-code "85577"^^xsd:string ;
   vcard:region "Bavaria"@en ;
   vcard:street-address "1234 Hepp Road"@en .


martin



Renato Iannella wrote:

> Hi all......I want to complete the vCard/RDF update soon...
>
> So the question remains....are we happy to use the rdf:value+type
> model (which is what the 2001 note uses)?
>
> If so, does this mean that we remove the homeTel Property (etc) from
> the ontology?
>
> Renato
>
> On 30 Jun 2009, at 19:17, Toby Inkster wrote:
>
>> Instead of:
>>
>>     _:me a v:VCard ;
>>          v:fn "Alice Smith" ;
>>          v:workTel <tel:[phone]> ;
>>          v:mobileTel <tel:[phone]> .
>>
>> It uses:
>>
>>     _:me a v:VCard ;
>>         v:fn "Alice Smith" ;
>>         v:tel [
>>             a vx:Tel ;
>>             rdf:value <tel:[phone]> ;
>>             vx:usage "work" , "mobile"
>>         ] .
>>
>> My primary motivation was to be able to represent the data in the hCard
>> microformat in a way more closely related to the type+value structure of
>> hCard communications devices.
>>
>> It's not perfect (it breaks the "range" of the 2006 v:tel, v:email and
>> v:label properties; and vx:usage should probably take a non-literal
>> value) but perhaps some of the ideas there could be incorporated into
>> the merged RDF vCard. In particular it should address all of the points
>> above.
>
> Cheers...  Renato Iannella
> NICTA
>
>

--
--------------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  mhepp@...
phone:   [phone]
fax:     [phone]
www:     http://www.unibw.de/ebusiness/ (group)
         http://www.heppnetz.de/ (personal)
skype:   mfhepp
twitter: mfhepp

Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
========================================================================

Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/

Talk at the Semantic Technology Conference 2009:
"Semantic Web-based E-Commerce: The GoodRelations Ontology"
http://tinyurl.com/semtech-hepp

Tool for registering your business:
http://www.ebusiness-unibw.org/tools/goodrelations-annotator/

Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe

Project page and resources for developers:
http://purl.org/goodrelations/

Tutorial materials:
Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey

http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009





[martin_hepp.vcf]

---

begin:vcard
fn:Martin Hepp
n:Hepp;Martin
org:Bundeswehr University Munich;E-Business and Web Science Research Group
adr:;;Werner-Heisenberg-Web 39;Neubiberg;;D-85577;Germany
email;internet:mhepp@...
tel;work:[phone]
tel;pager:skype: mfhepp
url:http://www.heppnetz.de
version:2.1
end:vcard

---

[Peter Mika-2]

>
> peter - would you share those publicly, please?

Sure, here is my cost/benefit analysis on tel as a resource:


Benefits:

-- Slightly easier data integration, e.g. using SPARQL queries. However,
how many people are doing data integration using SPARQL alone?
-- We would like to be compatible with the ontology... (or should the
ontology be changed?)

Costs:

-- Gives the illusion of a resource that you can dereference. Tom Heath
these days is on the road with an excellent Linked Data presentation
that explicitly advises against using non-http URIs.
-- There is not much anyone would ever want to say about a phone number,
which would be the most common reason for making something a resource.
-- Sites owner are expected to read an RFC on how to write down a
telephone number, and then figure out the transformation from their
internal representation to the scheme. Not likely to happen...
-- Search engines index URIs differently than literals or not at all. In
this case, this behaves as a literal in that I want it to be indexed.

Cheers,
Peter

>
> here is a pattern following the current yahoo recommendation:
>
> <http://www.heppnetz.de/searchmonkey/company.html#business> a
> gr:BusinessEntity, commerce:Business;
>   rdfs:label "Hepp Space Ventures Inc."@en ;
>   rdfs:seeAlso <http://www.heppnetz.de/>;
>   vcard:adr <http://www.heppnetz.de/searchmonkey/company.html#address> ;
>   vcard:fn "Hepp Space Ventures Inc."@en ;
>   vcard:geo
>       [ vcard:latitude "48.0802626"^^xsd:float ;
>         vcard:longitude "11.6407428"^^xsd:float
>       ] ;
>   vcard:tel "[phone]"^^xsd:string ;
>   vcard:url <http://www.heppnetz.de/> ;
>   foaf:depiction <http://www.heppnetz.de/searchmonkey/logo.png> .
>
>
> <http://www.heppnetz.de/searchmonkey/company.html#address> a
> vcard:Address ;
>   vcard:country-name "Germany"@en ;
>   vcard:locality "Neubiberg"@en ;
>   vcard:postal-code "85577"^^xsd:string ;
>   vcard:region "Bavaria"@en ;
>   vcard:street-address "1234 Hepp Road"@en .
>
>
> martin
>
>
>
> Renato Iannella wrote:
>> Hi all......I want to complete the vCard/RDF update soon...
>>
>> So the question remains....are we happy to use the rdf:value+type
>> model (which is what the 2001 note uses)?
>>
>> If so, does this mean that we remove the homeTel Property (etc) from
>> the ontology?
>>
>> Renato
>>
>> On 30 Jun 2009, at 19:17, Toby Inkster wrote:
>>
>>> Instead of:
>>>
>>>     _:me a v:VCard ;
>>>          v:fn "Alice Smith" ;
>>>          v:workTel <tel:[phone]> ;
>>>          v:mobileTel <tel:[phone]> .
>>>
>>> It uses:
>>>
>>>     _:me a v:VCard ;
>>>         v:fn "Alice Smith" ;
>>>         v:tel [
>>>             a vx:Tel ;
>>>             rdf:value <tel:[phone]> ;
>>>             vx:usage "work" , "mobile"
>>>         ] .
>>>
>>> My primary motivation was to be able to represent the data in the hCard
>>> microformat in a way more closely related to the type+value
>>> structure of
>>> hCard communications devices.
>>>
>>> It's not perfect (it breaks the "range" of the 2006 v:tel, v:email and
>>> v:label properties; and vx:usage should probably take a non-literal
>>> value) but perhaps some of the ideas there could be incorporated into
>>> the merged RDF vCard. In particular it should address all of the points
>>> above.
>>
>> Cheers...  Renato Iannella
>> NICTA
>>
>>
>

[Dan Brickley-2]

On 23/7/09 11:07, Peter Mika wrote:

>
>>
>> peter - would you share those publicly, please?
>
> Sure, here is my cost/benefit analysis on tel as a resource:
>
>
> Benefits:
>
> -- Slightly easier data integration, e.g. using SPARQL queries. However,
> how many people are doing data integration using SPARQL alone?
> -- We would like to be compatible with the ontology... (or should the
> ontology be changed?)
>
> Costs:
>
> -- Gives the illusion of a resource that you can dereference. Tom Heath
> these days is on the road with an excellent Linked Data presentation
> that explicitly advises against using non-http URIs.
> -- There is not much anyone would ever want to say about a phone number,
> which would be the most common reason for making something a resource.
> -- Sites owner are expected to read an RFC on how to write down a
> telephone number, and then figure out the transformation from their
> internal representation to the scheme. Not likely to happen...
> -- Search engines index URIs differently than literals or not at all. In
> this case, this behaves as a literal in that I want it to be indexed.

Also consider recent changes to vCard underway at IETF: see
http://danbri.org/words/2008/06/25/348 for a summary.

Latest seems to be
http://www.ietf.org/id/draft-ietf-vcarddav-vcardrev-08.txt

"""7.4.  Communications Properties

    These properties are concerned with information associated with the
    way communications with the object the vCard represents are carried
    out.

7.4.1.  TEL

    Purpose:  To specify the telephone number for telephony communication
       with the object the vCard represents.

    Value type:  A single URI value.  It is expected that the URI scheme
       will be "tel", as specified in [RFC3966], but other schemes MAY be
       used.
"""

Mention is also made of the mailto: URI scheme (surely this is still ok
to use, privacy issues aside), and a "geo" URI scheme
[I-D.mayrhofer-geo-uri] that I don't know much about.

If the goal of this vocabulary is to reflect the IETF vCard vocab,
keeping close to trends in vCard-land might be prudent...

cheers,

Dan

[Martin Hepp (UniBW)]

I personally think that alignment with the non-RDF vcard is only one
issue among others, as long as it is straightforward to populate the
vcard-RDF structures from vCards and vice versa.

What we really need is a consensual, practical schema for 90% of the
contact data in web resources.

Martin


Dan Brickley wrote:

> On 23/7/09 11:07, Peter Mika wrote:
>>
>>>
>>> peter - would you share those publicly, please?
>>
>> Sure, here is my cost/benefit analysis on tel as a resource:
>>
>>
>> Benefits:
>>
>> -- Slightly easier data integration, e.g. using SPARQL queries. However,
>> how many people are doing data integration using SPARQL alone?
>> -- We would like to be compatible with the ontology... (or should the
>> ontology be changed?)
>>
>> Costs:
>>
>> -- Gives the illusion of a resource that you can dereference. Tom Heath
>> these days is on the road with an excellent Linked Data presentation
>> that explicitly advises against using non-http URIs.
>> -- There is not much anyone would ever want to say about a phone number,
>> which would be the most common reason for making something a resource.
>> -- Sites owner are expected to read an RFC on how to write down a
>> telephone number, and then figure out the transformation from their
>> internal representation to the scheme. Not likely to happen...
>> -- Search engines index URIs differently than literals or not at all. In
>> this case, this behaves as a literal in that I want it to be indexed.
>
> Also consider recent changes to vCard underway at IETF: see
> http://danbri.org/words/2008/06/25/348 for a summary.
>
> Latest seems to be
> http://www.ietf.org/id/draft-ietf-vcarddav-vcardrev-08.txt
>
> """7.4.  Communications Properties
>
>    These properties are concerned with information associated with the
>    way communications with the object the vCard represents are carried
>    out.
>
> 7.4.1.  TEL
>
>    Purpose:  To specify the telephone number for telephony communication
>       with the object the vCard represents.
>
>    Value type:  A single URI value.  It is expected that the URI scheme
>       will be "tel", as specified in [RFC3966], but other schemes MAY be
>       used.
> """
>
> Mention is also made of the mailto: URI scheme (surely this is still
> ok to use, privacy issues aside), and a "geo" URI scheme
> [I-D.mayrhofer-geo-uri] that I don't know much about.
>
> If the goal of this vocabulary is to reflect the IETF vCard vocab,
> keeping close to trends in vCard-land might be prudent...
>
> cheers,
>
> Dan
>

--
--------------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  mhepp@...
phone:   [phone]
fax:     [phone]
www:     http://www.unibw.de/ebusiness/ (group)
         http://www.heppnetz.de/ (personal)
skype:   mfhepp
twitter: mfhepp

Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
========================================================================

Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/

Talk at the Semantic Technology Conference 2009:
"Semantic Web-based E-Commerce: The GoodRelations Ontology"
http://tinyurl.com/semtech-hepp

Tool for registering your business:
http://www.ebusiness-unibw.org/tools/goodrelations-annotator/

Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe

Project page and resources for developers:
http://purl.org/goodrelations/

Tutorial materials:
Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey

http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009





[martin_hepp.vcf]

---

begin:vcard
fn:Martin Hepp
n:Hepp;Martin
org:Bundeswehr University Munich;E-Business and Web Science Research Group
adr:;;Werner-Heisenberg-Web 39;Neubiberg;;D-85577;Germany
email;internet:mhepp@...
tel;work:[phone]
tel;pager:skype: mfhepp
url:http://www.heppnetz.de
version:2.1
end:vcard

---

[Peter Mika-2]

Yes, but you have to do the reality check: how many people have heard of

#1 http
#2 mailto
#3 tel
#4 geo
....

Peter

Dan Brickley wrote:

> On 23/7/09 11:07, Peter Mika wrote:
>>
>>>
>>> peter - would you share those publicly, please?
>>
>> Sure, here is my cost/benefit analysis on tel as a resource:
>>
>>
>> Benefits:
>>
>> -- Slightly easier data integration, e.g. using SPARQL queries. However,
>> how many people are doing data integration using SPARQL alone?
>> -- We would like to be compatible with the ontology... (or should the
>> ontology be changed?)
>>
>> Costs:
>>
>> -- Gives the illusion of a resource that you can dereference. Tom Heath
>> these days is on the road with an excellent Linked Data presentation
>> that explicitly advises against using non-http URIs.
>> -- There is not much anyone would ever want to say about a phone number,
>> which would be the most common reason for making something a resource.
>> -- Sites owner are expected to read an RFC on how to write down a
>> telephone number, and then figure out the transformation from their
>> internal representation to the scheme. Not likely to happen...
>> -- Search engines index URIs differently than literals or not at all. In
>> this case, this behaves as a literal in that I want it to be indexed.
>
> Also consider recent changes to vCard underway at IETF: see
> http://danbri.org/words/2008/06/25/348 for a summary.
>
> Latest seems to be
> http://www.ietf.org/id/draft-ietf-vcarddav-vcardrev-08.txt
>
> """7.4.  Communications Properties
>
>    These properties are concerned with information associated with the
>    way communications with the object the vCard represents are carried
>    out.
>
> 7.4.1.  TEL
>
>    Purpose:  To specify the telephone number for telephony communication
>       with the object the vCard represents.
>
>    Value type:  A single URI value.  It is expected that the URI scheme
>       will be "tel", as specified in [RFC3966], but other schemes MAY be
>       used.
> """
>
> Mention is also made of the mailto: URI scheme (surely this is still
> ok to use, privacy issues aside), and a "geo" URI scheme
> [I-D.mayrhofer-geo-uri] that I don't know much about.
>
> If the goal of this vocabulary is to reflect the IETF vCard vocab,
> keeping close to trends in vCard-land might be prudent...
>
> cheers,
>
> Dan

[Dan Brickley-2]

On 23/7/09 11:38, Peter Mika wrote:
> Yes, but you have to do the reality check: how many people have heard of
>
> #1 http
> #2 mailto
> #3 tel
> #4 geo
> ....

Don't shoot the messenger! I'm not advocating pro or anti on this. Both
options suck in different ways :)

But if you have a strong view, please do provide feedback to the IETF
through their preferred channels, before doing something under the vCard
brand that could be perceived as a "fork". I'd also suggest not using
language like "reality check" if you want them to take your feedback
positively, since it suggests the alternate design came from people who
were not realists...

cheers,

Dan

[Peter Mika-2]

Apologies for the strong language ;)

As Martin says, I don't think we are forking. It's in general our
audience that doesn't understand the difference between:

<a rel="vcard:tel" href="tel:[phone]"/>

and

<span property="vcard:tel">[phone]</span>

I'd be already happy if they knew what the + sign meant and that 1 is
the country code for the country in which they live in ;)

The authors of the vcard spec no doubt have a different audience, I
assume the makers of email/address book/calendaring software.

Cheers,
Peter


Dan Brickley wrote:

> On 23/7/09 11:38, Peter Mika wrote:
>> Yes, but you have to do the reality check: how many people have heard of
>>
>> #1 http
>> #2 mailto
>> #3 tel
>> #4 geo
>> ....
>
> Don't shoot the messenger! I'm not advocating pro or anti on this.
> Both options suck in different ways :)
>
> But if you have a strong view, please do provide feedback to the IETF
> through their preferred channels, before doing something under the
> vCard brand that could be perceived as a "fork". I'd also suggest not
> using language like "reality check" if you want them to take your
> feedback positively, since it suggests the alternate design came from
> people who were not realists...
>
> cheers,
>
> Dan
>

[Dan Brickley-2]

On 23/7/09 12:05, Peter Mika wrote:

> Apologies for the strong language ;)
>
> As Martin says, I don't think we are forking. It's in general our
> audience that doesn't understand the difference between:
>
> <a rel="vcard:tel" href="tel:[phone]"/>
>
> and
>
> <span property="vcard:tel">[phone]</span>
>
> I'd be already happy if they knew what the + sign meant and that 1 is
> the country code for the country in which they live in ;)

Likewise :)

> The authors of the vcard spec no doubt have a different audience, I
> assume the makers of email/address book/calendaring software.

I think we may need "fat" vocabs that allow both idioms, and then
smaller communities that define profiles that make stricter subsets. At
least, this is my thinking w.r.t. FOAF and how to incorporate much of
Portable Contacts, while making room for SemWebby richness...

Dan

[Norman Walsh]

"Martin Hepp (UniBW)" <martin.hepp@...> writes:
> I personally think that alignment with the non-RDF vcard is only one
> issue among others, as long as it is straightforward to populate the
> vcard-RDF structures from vCards and vice versa.
>
> What we really need is a consensual, practical schema for 90% of the
> contact data in web resources.

Exactly. One of the principles that I was trying to follow was "don't
invent anything", just model an existing standard in RDF. If the
broader group has different design principles in mind, that's
perfectly fine with me.

                                        Be seeing you,
                                          norm

--
Norman Walsh <ndw@...> | One's never alone with a rubber duck.
http://nwalsh.com/            |

[Renato Iannella]

Thanks for the discussion everyone....

Firstly, the 2001 Note and 2006 Ontology were focussed on vCard 3.0....

Since vCard 4.0 is close to final...not that many changes to  
go...should we simply say....leave the NOTE/Ontology as they are and  
lets do the RDF for vCard 4.0 ?

Comments?

Cheers...  Renato Iannella
NICTA