Re: Notes from today's meeting

Hi All,

I wanted to discuss one more thing that has been decided in an earlier
meeting.
And that is the choice for dcterms:created or pav:createdOn.
As a large data provider I want to only share the date that I published the
data on.
i.e. dcterms:issued. Could we change the must to include issued next to
created or createdOn.

This is also a crucial date for the general public while created is not.
(e.g. for patent court cases date of publication is critical, the day the
file was internally ready is not)

Also continuing the discussion on e-mail that started on the call.
We should have a clear definition of data item if we are going to record
information about such things. e.g. baseURI, what happens if we have 2 data
item types in a single dataset?

About void:inDataset I personally don't like it. I suspect it would cost me
a 13% growth in triple size for negligible benefits. This also means that
the dataset description starts to affect the data. Although I could only
present this in the rest / linked data interface and not in the sparql
endpoint. I am worried that I can not put it into the FTP data dump rdf. As
the data item concept does not map 1:1 on a set of triples that are atomic.

e.g. someone can use just the UniProtKB sequences. Once they did that is it
still the same dataset that I published it as? I don't think so. Which
means uniprot end users need to be careful to remove more triples. Which
why I disagree with alasdair's call for MUST.

Regards,
Jerven

Regards,
Jerven


Regards,
Jerven







On Mon, Jun 3, 2013 at 6:11 PM, Alasdair J G Gray <
Alasdair.Gray@manchester.ac.uk> wrote:

> Hi All,
>
> Seems that fuse threw everyone out at the crucial moment. We will pick up
> the void:inDataset discussion next week as well as addressing the
> provenance section.
>
> Attached are the notes I made during today's call.
>
> Alasdair
>
>
>
> Dr Alasdair J G Gray
> Research Associate
> Alasdair.Gray@manchester.ac.uk
> +44 161 275 0145
>
> http://www.cs.man.ac.uk/~graya/
>
> Please consider the environment before printing this email.
>
>
>


-- 
Jerven Bolleman
me@jerven.eu