Property for specifying contact information for a dataset
GoogleCodeExporter opened this issue · 7 comments
GoogleCodeExporter commented
[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 commented
Original comment by Michael.Hausenblas
on 20 Jan 2011 at 12:00
- Changed state: Accepted
- Added labels: Milestone-Release2.0
GoogleCodeExporter commented
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 commented
Marking as “SWIG feedback”
Original comment by richard....@gmail.com
on 3 Feb 2011 at 4:15
- Added labels: SWIG-feedback
GoogleCodeExporter commented
Implemented new sec 2.3 as of comment #2 here, see r184
Original comment by Michael.Hausenblas
on 9 Feb 2011 at 3:24
GoogleCodeExporter commented
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 commented
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 commented
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