Property for specifying contact information for a dataset

[GoogleCodeExporter]

[See also: http://chatlogs.planetrdf.com/swig/2011-01-17.html#T13-04-17]

I'd like to be able to annotate a dataset with contact details should people 
have queries or corrections. I've been unable to find any way that is suitably 
extensible for what I'd like to do with it. Hence, I'd like to suggest a 
void:contact property.

In a number of cases, the contact e-mail address will differ from that of the 
publisher, creator, maintainer or rightsHolder, particularly when there is a 
dedicated e-mail address for the dataset (and the maintainer etc. have greater 
concerns than just the one dataset).

There is the option of giving the maintainer as "the people who look after the 
dataset", being a sub-organisation of the public-facing organisation. However, 
it may not always be appropriate or desirable to expose that level of detail, 
particularly if you want the public-facing organisation to be credited as 
maintainer.

I would suggest that the range of void:contact be one of the power set of 
e-mail URI, v:VCard and foaf:Agent.

Original issue reported on code.google.com by asd.ox.a...@googlemail.com on 17 Jan 2011 at 2:12

[GoogleCodeExporter]

Original comment by Michael.Hausenblas on 20 Jan 2011 at 12:00

• Changed state: Accepted
• Added labels: Milestone-Release2.0

[GoogleCodeExporter]

The recommended approach is to pick the closest relationship from the DC 
vocabulary (probably dcterms:publisher), and attach contact information to that 
entity. That approach seems to hit the 80/20 point and avoids adding another 
term that partially overlaps in meaning with existing terms.

In cases where this is inappropriate, one can always provide contact 
information on the dataset's foaf:homepage.

I propose to address this issue by explicitly documenting the pattern described 
above. Proposed text below:

<h3>2.3 Contact Information</h3>

<p>Potential users of a dataset may want to get in touch with the publisher or 
other contributors. Contact information can be attached to any of the entities 
that are given as the <code>dcterms:publisher</code>, 
<code>dcterms:creator</code> and <code>dcterms:contributor</code> of a dataset. 
In particular, <a href="http://xmlns.com/foaf/spec/#term_mbox">the 
<code>foaf:mbox</code> property</a> [<a href="#ref-FOAF">FOAF</a>] can be used 
to specify that entity's contact email address.</p>

<p>The following example shows how to provide a contact email address for the 
publisher of a dataset:</p>

<pre>
:ExampleDataset a void:Dataset;
    dcterms:publisher :Alice;
    .
:Alice a foaf:Person;
    rdfs:label "Alice McExample";
    foaf:mbox <mailto:alice@example.com>;
    .
</pre>

<p>If the publisher were an organization, then typing it as 
<code>foaf:Organization</code> would be appropriate.</p>

Original comment by richard....@gmail.com on 20 Jan 2011 at 12:42

[GoogleCodeExporter]

Hi Richard,

I'm sorry for not having expressed this adequately well. Here are some examples 
of cases not modelled by using dcterms:publisher:

:ExampleDataset a void Dataset ;
    dcterms:publisher :ExampleOrg ;
    void:contact :Alice .

:ExampleOrg a foaf:Organization ;
    foaf:mbox <mailto:enquiries@example.com> .

:Alice a foaf:Person ;
    bio:event [ a bio:Employment ; bio:employer :ExampleOrg ] ;
    foaf:mbox <mailto:alice@example.com> .

(Alice is the nominated contact for enquiries about the dataset, but publishing 
and maintenance are carried out by the organisation as a whole. Alice's email 
address isn't the contact point for the publisher more generally.)

As another example, if :SomeOrg has 10 datasets they may wish to create an 
e-mail address for dataset so as to allow them to internally direct queries to 
the right people. If instead we'd done …:

:FooDataset a void:Dataset ;
    dcterms:publisher :ExampleOrg .

:ExampleOrg a foaf:Organization ;
    foaf:name "Example Organization" ;
    foaf:mbox <mailto:foo-dataset@example.com> .

:BarDataset a void:Dataset ;
    dcterms:publisher :ExampleOrg .

:ExampleOrg a foaf:Organization ;
    foaf:name "Example Organization" ;
    foaf:mbox <mailto:bar-dataset@example.com> .

… it would be reasonable to assume that the (foo|bar)-enquiries@example.com 
addresses may be used for more general enquiries. When one then conflates the 
foaf:Organization descriptions for each dataset then it ends up with lots of 
dataset-specific e-mail addresses alongside the official 'general enquiries' 
one. A contact property would allow the following:

:FooDataset a void:Dataset ;
    dcterms:publisher :ExampleOrg ;
    void:contact [ a foaf:Agent ; foaf:mbox <mailto:foo-dataset@example.com> ] .

:BarDataset a void:Dataset ;
    dcterms:publisher :ExampleOrg ;
    void:contact [ a foaf:Agent ; foaf:mbox <mailto:foo-dataset@example.com> ] .

:ExampleOrg a foaf:Organization ;
    foaf:name "Example Organization" ;
    foaf:mbox <mailto:enquiries@example.com> .

Kind regards,

Alex

Original comment by asd.ox.a...@googlemail.com on 24 Jan 2011 at 10:10

[GoogleCodeExporter]

I understand these scenarios, but I'm not convinced that they are sufficiently 
widespread or typical to warrant a new property. The always applicable fallback 
is not to provide machine-readable contact information, but to put the details 
onto the foaf:homepage instead.

Original comment by richard....@gmail.com on 24 Jan 2011 at 9:38

[GoogleCodeExporter]

Alex, for clarification: My proposed text above really doesn't address your 
issue at all. It just addresses a gap in the current document that was 
highlighted by your comment. We decided today in the editors' call to include 
that text, and to reconsider this issue after the current release of voiD (when 
hopefully we have more information available on how common this use case is).

In the meantime, we encourage you to create a xxx:contact property outside of 
the void namespace (e.g., at OpenVocab).

Original comment by richard....@gmail.com on 1 Feb 2011 at 11:27

• Added labels: Milestone-Release3.0, Type-Enhancement
• Removed labels: Milestone-Release2.0, Type-Defect

[GoogleCodeExporter]

Marking as “SWIG feedback”

Original comment by richard....@gmail.com on 3 Feb 2011 at 4:15

• Added labels: SWIG-feedback

[GoogleCodeExporter]

Implemented new sec 2.3 as of comment #2 here, see r184

Original comment by Michael.Hausenblas on 9 Feb 2011 at 3:24