Re: Is vCard range restriction on org:siteAddress necessary?

On Tue, 2011-01-04 at 11:02 -0500, Tim Berners-Lee wrote: 
> I wish the conflation of a VCard and a SocialEntity whose card it is
> were
> either ruled out completely or asserted completely by statements in
> the ontology.

+1

> I personally find that the class of "business card" is one which I do
> not
> want to have any data about.  (In fact for me it maps best 
> not to a node in the graph but to the RDF document whose contents is
> the graph.
> Important for provenance in that respect, but not part of this
> ontology).

The use case that I've come across has been bundling sets of contact
mechanisms together. 

For example, in local government there can be a main contact point for a
Council (with email, phone, mail address, web form) and then contact
points for out of hours use or for specific services (each potentially
with multiple contact mechanisms). 

This grouping-for-a-purpose is different from grouping by organization
or grouping by site (e.g. the council main offices may have both a
normal and an out-of-hours set of contact details). 

Dave

> 
> My personal take on this in 1990 was the contact: ontology, which had
> the classes
> 
> 
> SocialEntity (subclasses: Person, Organization)
> and
> Location
> 
> 
> and properties 
> 
> 
> home, work, vacation
> 
> 
> link a Person (say) to a Location.  Locations 
> 
> 
> Similarly I could imagine properties like
> 
> 
> site, headquarters, deliveriesPlease, corporateSeat
> 
> 
> would link an Organization to a Location.
> 
> 
> (I was extra careful in making street, city, postcode, country
> properties of the address of a location not of the location itself,
> allowing a location to have >1 address, or two organizations to have
> notional locations which were different and had different phone
> numbers but the same address.
> I used it for mapping my contact stuff out of Outlook into RDF.  I
> needed "assistant" as Outlook has "Asssitant phone number".)
> 
> 
> In all this a "card" has no useful place I can see.  Nor is there a
> 1-1 correspondence between it and anything except for possibly
> SocialEntity.  So I would be in favour of the practice of translating
> VCards into information about a Social Entity (or an Organization or a
> Person), and not a card.
> 
> 
> Tim
> 
> 
> ________
> 
> 
> 
> 
> 
> 
> 
> On 2011-01 -04, at 09:03, Dave Reynolds wrote:
> 
> > On Tue, 2011-01-04 at 13:28 +0100, William Waites wrote: 
> > > * [2011-01-04 11:49:43 +0000] Dave Reynolds
> > > <dave.e.reynolds@gmail.com> écrit:
> > > 
> > > ] Is VCard that bad? It fits your example below just fine.
> > > 
> > > The only problem I see with the example is that we don't have
> > > counties
> > > in Scotland, we have districts. In Quebec and Louisiana and other
> > > historically catholic places we have parishes. Is Scotland a
> > > "state"
> > > in the American sense, not really. You could use things like
> > > vc:county
> > > and vc:state and just say that the naming is bad, I guess.
> > 
> > Agreed, that's one reason not to make up another set of address
> > terms
> > such as Phil's ex: examples.
> > 
> > The vcard terms (locality, region) strike me as reasonably neutral
> > whereas ex:county is not.
> > 
> 
> 
> Yes.  In fact, a convention for mapping between them
> would be useful, even if it is in the comments in the ontology
> so that if you click though from locality is says "such as a city (US)
> or parish (Scotland)".
> Guidance for ontology users in the ontology file is useful.
> 
> 
> (Presumably e.g. OSX's Address Book has defined this mapping as they
> will format all your addresses (whatever country they are in) in your
> chosen
> local style of any of many countries.)
> 
> 
> Tim
> 
> 
> 
> 
> 
> 
> 
> Address
> type
> Class
> contact point
> type
> Class
> comment
> A place, or
> mobile situation,
> with address,
> phone number,
> fax, etc. Related
> to a person by
> home, office,
> etc. Note one
> person's
> workplace may be
> another person's
> home. A person
> may have more
> than one home and
> more than one
> workplace. (In
> practice it
> sometimes maybe
> useful with
> restriucted
> datasets to
> assume that this
> is not the case,
> when extracting
> data from other
> ontologies with
> no concept of
> ContactLocation).
> Strongly related
> to a person: in
> some ways a role
> that a person can
> be in.
> label
> contact point
> fax
> label
> fax
> subClassOf
> phone
> Female
> type
> Class
> Language Code
> type
> Class
> Male
> type
> Class
> mobile
> label
> mobile
> subClassOf
> phone
> Pager
> subClassOf
> phone
> Person
> comment
> A person in the
> normal sense of
> the word.
> subClassOf
> Social Entity
> phone
> type
> Class
> comment
> An end-point in
> the public
> swiitched
> telephone system.
> Anything
> identified by a
> URI with tel:
> scheme is in this
> class. 
> label
> phone
> tel.
> Social Entity
> type
> Class
> comment
> The sort of thing
> which can have a
> phone number.
> Typically a
> person or an
> incorporated
> company, or
> unincorporated
> group.
> subject to change
> label
> subject to change
> address Property
> type
> Property
> address
> type
> Property
> domain
> contact point
> label
> address
> range
> Address
> assistant
> type
> Property
> comment
> A person (or
> other agent) who
> is an assistant
> to the subject.
> domain
> http://xmlns.com/foaf/0.1/Agent
> label
> assistant
> ramge
> http://xmlns.com/foaf/0.1/Agent
> birthday
> type
> Property
> domain
> Social Entity
> range
> Date
> child
> type
> Property
> city
> domain
> Address
> country
> domain
> Address
> department Name
> domain
> Person
> description
> type
> Property
> email
> type
> InverseFunctionalProperty
> comment
> emailAddress is a
> string. Use of
> this is
> discouraged.
> Use :mailbox
> instead 
> domain
> Social Entity
> label
> email
> range
> Email Address
> example
> 
> 
> 
> 
> 
> 
> 
> 
> emergency only
> type
> Property
> domain
> Person
> label
> emergency only
> range
> contact point
> family Name
> domain
> Person
> fax
> type
> Property
> domain
> contact point
> range
> fax
> first Name
> domain
> Person
> full name
> type
> Property
> label
> full name
> given Name
> domain
> Person
> home
> type
> Property
> domain
> Person
> label
> home
> range
> contact point
> home Page
> type
> InverseFunctionalProperty
> subPropertyOf
> web page
> address Property
> home Page Address
> home Page Address
> type
> InverseFunctionalProperty
> comment
> Use is
> discouraged
> name
> type
> Property
> comment
> A person may be
> known as various
> strings. For
> example, an email
> friendly name
> string. If you
> have an email
> from someone
> using a string as
> the
> human-readable
> phrase, then it
> is reasonable to
> assume that there
> are :knownAs
> that.
> label
> name
> last Name
> domain
> Person
> mailbox
> type
> InverseFunctionalProperty
> domain
> Social Entity
> range
> Mailbox
> address Property
> mailbox URI
> example
> Dan
> mailbox URI
> type
> InverseFunctionalProperty
> comment
> mailboxURI is a
> string. Use of
> this is
> discouraged.
> Use :mailbox
> instead 
> domain
> Social Entity
> range
> URI
> example
> Dan
> middle Initial
> domain
> Person
> middle Name
> domain
> Person
> mobile
> type
> Property
> domain
> Person
> label
> mobile
> range
> contact point
> mother Tongue
> type
> Property
> domain
> Person
> range
> Language Code
> nearest airport
> type
> Property
> comment
> ?X
> nearestAirport ?Y
> locates ?X in an
> international
> context; for
> example, for the
> purpose of
> organizing a
> face-to-face
> meeting of a W3C
> working group.
> This property is
> intended to
> mitigate privacy
> risks of giving
> out detailed
> contact info.
> label
> nearest airport
> seeAlso
> http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0006.html
> 9
> http://www.w3.org/2001/sw/Europe/200303/geo/intro.html
> http://www.w3.org/2001/sw/WebOnt/webont-airports.rdf
> http Range 14
> work
> type
> Property
> domain
> Person
> label
> work
> range
> contact point
> organization
> domain
> Person
> participant
> type
> Property
> comment
> A person (or
> other agent) who
> particpates in an
> event, meeting,
> etc.
> label
> participant
> ramge
> http://xmlns.com/foaf/0.1/Agent
> partner
> type
> Property
> domain
> Person
> range
> Person
> personal Suffix
> domain
> Person
> personal Title
> domain
> Person
> phone
> type
> Property
> domain
> contact point
> range
> phone
> postal Code
> domain
> Address
> preferred
> type
> Property
> comment
> A string which is
> the URI a person,
> organization,
> etc, prefers that
> people use for
> them.
> label
> preferred
> public Home Page
> subPropertyOf
> home Page
> sort name
> type
> Property
> comment
> re-arranged for
> lexicographic
> ordering; ala
> Doe, John
> label
> sort name
> region
> type
> Property
> domain
> Address
> label
> region
> street
> domain
> Address
> street2
> domain
> Address
> street3
> domain
> Address
> title
> domain
> Person
> vacation
> type
> Property
> domain
> Person
> label
> vacation
> range
> contact point
> web page
> type
> Property
> comment
> A related web
> page
> label
> web page
> zip
> subPropertyOf
> postal Code
> persistence Policy
> seeAlso
> http://www.w3.org/1999/10/nsuri
> 
>

Received on Tuesday, 4 January 2011 17:04:15 UTC