W3C home > Mailing lists > Public > public-gld-wg@w3.org > January 2012

Re: ISSUE-23: How to relate a person to a building/room? [People]

From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
Date: Mon, 30 Jan 2012 16:23:44 +0200
Message-ID: <CANaM+WFAzp1UsqbhbqjzXEMHrg+L-MF0Z7MDm24ah8HsGxdXQw@mail.gmail.com>
To: Michael Hausenblas <michael.hausenblas@deri.org>
Cc: Government Linked Data Working Group WG <public-gld-wg@w3.org>
Michael, all, hi.

If it's important for your application that you distinguish individual
rooms, you must extend VCard so that individual rooms are
representible. VCard, IIRC, has handles for extending with
application-specific fields. You can then simply do this:

<http://colcids.com/person/42> org:basedAt :r101 .
:r101 rdf:type org:Site ;
   org:siteAdress [ something VCard that says Room 101 at Building CCHQ ].

This particular mini-Site is the org:siteOf the org:OrganizationalUnit
that <http://colcids.com/person/42> is org:memberOf.

Org does not have a subSite property, but that's not really necessary here.

This is my spec-writing 2c.

My academic 2c would involve creating a schema that allows one to
infer that a site address that points to Building CCHQ subsumes all
site addresses that point to individual rooms in the building. But I
don't think this is necessary for our purposes, all we need is a way
to represent how somebody can be reached.

Unless I am mistaken about why we need to model rooms and buildings
and there is a requirement that I have missed somewhere. Hence my
original question about what the intended usage is.

Best,
Stasinos



On 30 January 2012 09:46, Michael Hausenblas
<michael.hausenblas@deri.org> wrote:
>
> Stasinos,
>
>
>> If the intended usage is one of describing organizational structure,
>> the Org ontology (or whatever we end up using to represent
>> organizations) should be adequate, as arbitrarily small
>> OrganizationUnitS can have individual hasSite properties, which can be
>> arbitrarily fine-grained, down to a desk in an office in a building at
>> an address somewhere on the planet. Again, it's a matter of allowing a
>> fine enough address schema.
>
>
>
> I'm not disagreeing here, but we're in the spec writing business and not
> having an academic discussion.
>
>
> Can you please provide me with a Turtle snippet in ORG + vCard that does the
> same as:
>
> [[
> @prefix rooms: <http://vocab.deri.ie/rooms#> .
> @prefix : <>. <http://colcids.com/person/42> a foaf:Person .
>  :CCHQ a rooms:Building ;
>  rooms:contains :r101 .
>
>  :r101 a rooms:Room ;
>  rooms:occupant <http://colcids.com/person/42> .
> ]]
>
>
> Cheers,
>        Michael
>
> --
> Dr. Michael Hausenblas, Research Fellow
> LiDRC - Linked Data Research Centre
> DERI - Digital Enterprise Research Institute
> NUIG - National University of Ireland, Galway
> Ireland, Europe
> Tel. +353 91 495730
> http://linkeddata.deri.ie/
> http://sw-app.org/about.html
>
> On 30 Jan 2012, at 07:26, Stasinos Konstantopoulos wrote:
>
>> Still, it seems to me that this is not a separate issue.
>>
>> If the intended usage is one of finding out how to reach people, it is
>> a matter of defining/choosing a contact information schema that is
>> detailed enough to achieve this.
>>
>> If the intended usage is one of describing organizational structure,
>> the Org ontology (or whatever we end up using to represent
>> organizations) should be adequate, as arbitrarily small
>> OrganizationUnitS can have individual hasSite properties, which can be
>> arbitrarily fine-grained, down to a desk in an office in a building at
>> an address somewhere on the planet. Again, it's a matter of allowing a
>> fine enough address schema.
>>
>> s
>>
>>
>> On 30 January 2012 09:07, Michael Hausenblas
>> <michael.hausenblas@deri.org> wrote:
>>>
>>>
>>> Stasinos,
>>>
>>> Thanks for your question.
>>>
>>>
>>>> What is the use case for this?
>>>
>>>
>>>
>>>
>>> For example, we use it in http://lab.linkeddata.deri.ie/2010/deri-rooms
>>> ...
>>>
>>>
>>>> I mean, how is this different from
>>>> representing contact information for a person (ISSUE 24)?
>>>
>>>
>>>
>>>
>>> See [1] - in a sense an extension of contact information with potentially
>>> finer granular descriptions than an address.
>>>
>>> Cheers,
>>>       Michael
>>>
>>> [1]
>>>
>>> https://dvcs.w3.org/hg/gld/raw-file/default/people/index.html#relating-a-person-to-a-building-or-room
>>> --
>>> Dr. Michael Hausenblas, Research Fellow
>>> LiDRC - Linked Data Research Centre
>>> DERI - Digital Enterprise Research Institute
>>> NUIG - National University of Ireland, Galway
>>> Ireland, Europe
>>> Tel. +353 91 495730
>>> http://linkeddata.deri.ie/
>>> http://sw-app.org/about.html
>>>
>>> On 30 Jan 2012, at 07:02, Stasinos Konstantopoulos wrote:
>>>
>>>> Michael, all,
>>>>
>>>> What is the use case for this? I mean, how is this different from
>>>> representing contact information for a person (ISSUE 24)?
>>>>
>>>> Best,
>>>> Stasinos
>>>>
>>>>
>>>> On 29 January 2012 13:07, Government Linked Data Working Group Issue
>>>> Tracker <sysbot+tracker@w3.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>> ISSUE-23: How to relate a person to a building/room? [People]
>>>>>
>>>>> http://www.w3.org/2011/gld/track/issues/23
>>>>>
>>>>> Raised by: Michael Hausenblas
>>>>> On product: People
>>>>>
>>>>> There are really two issues here, namely how to represent buildings and
>>>>> rooms  and how to relate a person to the building/room. It seems that
>>>>> the
>>>>> Buildings and Rooms Vocabulary [1] would in fact be capable to do this,
>>>>> however the namespace is sub-optimal, in terms of stability.
>>>>>
>>>>> [1] http://vocab.deri.ie/rooms#
>>>>>
>>>>>
>>>>>
>>>>
>>>
>
Received on Monday, 30 January 2012 14:24:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 June 2013 15:04:56 UTC