<scribe> scribe: PhilA
fadmaa: want to go through the issues, most have proposals
<Makx> I can barely hear fadi
<fadmaa> http://www.w3.org/2011/gld/wiki/Data_Catalog_Vocabulary/AccessURLRedesign
very hard to hear you fadmaa
<fadmaa> http://www.w3.org/2011/gld/wiki/Dcat_examples
<Makx> +q
<Makx> -q
Makx: We're working with the
European Publications Office to create an application profile
for DCAT so that data sets can be fund by a central
service
... my priority is to get DCAT finalised
... I'm happy with the current proposal
... based on ADMS approach to the issue
cygri: I have a question
... Do we have a proposed spec text? Or do we have to go by the
skets of the design in withe wiki page
fadmaa: I wasn't sure if I could edit the text before the meeting
cygri: Main simplification is that it does away with the sub classes
<Makx> +q
cygri: but we need to make a distinction between different access methods
martin_: This matches our experience - all in line with this proposal. We haven't had landing page and downloadURL but would be compatible
Makx: A question - isee that downloadURL is a sub prop of accessURL - why?
cygri: Because download is a form of access
Makx: But how would it be used (by someone that doesn't know the difference?
cygri: accessURL could be
anything - you don't know for sure what it points to. Web page,
form, whatever
... if you know it goes straight to a download then you can use
downloadURL
... the distinction is not made in some catalogues
<fadmaa> sorry what was the code?
Makx: Yes, but why is download a
sub prop of access
... So if I doon't know the difference then I should treat
downloadURL as accessURL?
... OKm got it
<Makx> +1 distribution proposal
PROPOSAL: ACCEPT http://www.w3.org/2011/gld/wiki/Data_Catalog_Vocabulary/AccessURLRedesign
<martin_> +1
<fadmaa> +1
atemezin: To be consistent, should accessURL be webpageURL?
cygri: downloadURL and accessURL might not be a web page
<Makx> shouldn't landingPage be a URI rather than URL?
<cygri> +1
fadmaa: We were thinking of using foaf:page but we're more specific - a page where you can get access to the pag
<atemezin> @cygri: my previous question was about landingPage actually
<atemezin> changing landingPage to webPageURL
hasChannel
cygri: landingPage is consistent
with foaf
... we can't call accessURL and downloadURL pages
... So for consistency I think we should stick to what we
have
re proposal +1
<atemezin> +1
<Makx> +1
<martin_> +1
RESOLUTION: http://www.w3.org/2011/gld/wiki/Data_Catalog_Vocabulary/AccessURLRedesign is accepted
atemezin: Should we define landingPage as a sub prop of foaf:page
<cygri> "The page property relates a thing to a document about that thing."
<fadmaa> list of issues http://www.w3.org/2011/gld/track/products/2
fadmaa: 8 and 9 are now
covered
... ISSUE-43 was around renaming (from Rufus)
<Makx> -1
<cygri> PROPOSAL: stick to dcat:Distribution
<Makx> +1
<fadmaa> +1
fadmaa: my suggestion is to ask people whether they prefer Distribution or resource?
<martin_> +1 (Distribution)
<Makx> Distribution
<atemezin> +1 (Distribution)
PROPOSED RESOLUTION: Stick to dcat:Distribution?
+1
<Makx> +1
RESOLUTION: Stick to dcat:Distribution?
close ISSUE-43
<trackbot> Closed ISSUE-43 rename dcat:Distribution to Resource.
<cygri> ISSUE-10?
<trackbot> ISSUE-10 -- Refine dcat:granularity to dcat:spatialGranularity and dcat:temporalGranularity -- pending review
<trackbot> http://www.w3.org/2011/gld/track/issues/10
fadmaa: ISSUE-10
ISSUE-10?
<trackbot> ISSUE-10 -- Refine dcat:granularity to dcat:spatialGranularity and dcat:temporalGranularity -- pending review
<trackbot> http://www.w3.org/2011/gld/track/issues/10
fadmaa: proposal is to drop granularity - possibly come back to it later -DCAT2
<cygri> PROPOSAL: Close ISSUE-10 by dropping dcat:granularity, as it is underspecified
<Makx> +1 to move to future
PhilA: +1 to dropping it - but it may well come back as a separate vocab
fadmaa: The feeling is that
granularity is useful, but we don't have enough data to put it
in DCAT today
... It's useful buyt we can't reocmmend a proper use of it
today
RESOLUTION: Drop dcat:granularity
ISSUE-10 close
close ISSUE-10
<trackbot> Closed ISSUE-10 Refine dcat:granularity to dcat:spatialGranularity and dcat:temporalGranularity.
<fadmaa> http://www.w3.org/2011/gld/track/issues/12
<cygri> ISSUE-12?
<trackbot> ISSUE-12 -- What values to use to describe formats of dcat:Distribution? -- pending review
<trackbot> http://www.w3.org/2011/gld/track/issues/12
ISSUE-12?
<trackbot> ISSUE-12 -- What values to use to describe formats of dcat:Distribution? -- pending review
<trackbot> http://www.w3.org/2011/gld/track/issues/12
proposal is to have a new prop of media type - value is a one defined by IANA
if it doesn't exist... (shape files etc.) then use dcformat with any value
<martin_> Resolved in http://www.w3.org/2011/gld/meeting/2012-10-25#resolution_3 ??
ISSUE-12 was already closed, sorry, shouldn't have come up today
close ISSUE-12
<trackbot> Closed ISSUE-12 What values to use to describe formats of dcat:Distribution?.
<fadmaa> issue-13 ?
<trackbot> ISSUE-13 -- attach specific properties to dcat:Distribution and not to dcat:Dataset -- pending review
<trackbot> http://www.w3.org/2011/gld/track/issues/13
ISSUE-13?
<trackbot> ISSUE-13 -- attach specific properties to dcat:Distribution and not to dcat:Dataset -- pending review
<trackbot> http://www.w3.org/2011/gld/track/issues/13
fadmaa: We got the feedback we
needed. So I think we're OK on that...
... Had feedback from Makx, it's in line with ADMS, title,
description, modified and issued
<atemezin> +1
<Makx> still +1
<cygri> PROPOSAL: Recommend that title, description, modified, issued can also be used on distributions, not just datasets
<cygri> +1
<fadmaa> +1
<Makx> +1
<Makx> just adding
<martin_> +1
martin_: Do we add those to distribution and keep them from dataset?
fadmaa: Both - i.e. keep all of them on both
<fadmaa> issue-53 ?
<trackbot> ISSUE-53 -- Move the license property from dataset to distribution -- pending review
<trackbot> http://www.w3.org/2011/gld/track/issues/53
RESOLUTION: Recommend that title, description, modified, issued can also be used on distributions, not just datasets
CLOSE issue-13
<trackbot> Closed ISSUE-13 attach specific properties to dcat:Distribution and not to dcat:Dataset.
fadmaa: We currently have licence on datasets but feedback said it could be different per distribution
<Makx> ADMS has licence for Distribution not for Asset/DataSet
fadmaa: I got +1 from Makx
PROPOSED RESOLUTION: Move dcterms:license from Dataset to Distribution
<Makx> +1
<cygri> +1
+1
<fadmaa> +1
<martin_> +1
RESOLUTION: Move dcterms:license from Dataset to Distribution and Close ISSUE-13
<fadmaa> issue-52 ?
<trackbot> ISSUE-52 -- Drop dc:reference from Dcat -- pending review
<trackbot> http://www.w3.org/2011/gld/track/issues/52
Close ISSUE-13
<trackbot> Closed ISSUE-13 attach specific properties to dcat:Distribution and not to dcat:Dataset.
<Makx> dc:refernce does not exist
<Makx> http://dublincore.org/documents/dcmi-terms/#terms-references
fadmaa: dcterms:reference is too generic to be useful. So we can just leave it out of the spec. They can still use it of course
<cygri> it's references, not reference :-)
<Makx> so it's dc:references with s at the end
<Makx> OK to drop
PROPOSED RESOLUTION: Drop dcterms:references from the spec (which doesn't make it illegal to use) and close ISSUE-13
<Makx> +1
<cygri> +1
<martin_> +1
+1
<atemezin> +1
RESOLUTION: Drop dcterms:references from the spec 9which doesn't make it illegal to use) and close ISSUE-13
close ISSUE-13
<trackbot> Closed ISSUE-13 attach specific properties to dcat:Distribution and not to dcat:Dataset.
ISSUE-11?
<trackbot> ISSUE-11 -- Is dcat:CatalogRecord related to Named Graphs? -- open
<trackbot> http://www.w3.org/2011/gld/track/issues/11
ISSUE-14?
<trackbot> ISSUE-14 -- add dcat:permanentIdentifier property -- open
<trackbot> http://www.w3.org/2011/gld/track/issues/14
<fadmaa> issue-11 ?
<trackbot> ISSUE-11 -- Is dcat:CatalogRecord related to Named Graphs? -- open
<trackbot> http://www.w3.org/2011/gld/track/issues/11
ISSUE-54?
<trackbot> ISSUE-54 -- Relationship of DCAT and VoID -- raised
<trackbot> http://www.w3.org/2011/gld/track/issues/54
cygri: I've been looking at these this morning
<cygri> http://www.w3.org/mid/5E2B5125-A4F7-4D3D-871E-0FD05EA9B7BD@cyganiak.de
cygri: issue-11 there probably is some sort of relationship
<cygri> In web-based catalogs that provide an individual page for each dataset, the URL of that page can be used as the IRI of the catalog record if it is a permalink. This is specially appropriate if the page provides access to an RDF description of the dataset via content negotiation [[RFC2616]], embedded RDFa markup, or similar mechanisms.
<cygri> If a catalog is represented as an RDF Dataset [[RDF11-Concepts]] with named graphs, then it is appropriate to place the description of each dataset (consisting of all RDF triples that mention the dcat:Dataset, dcat:CatalogRecord, and any of its dcat:Distributions) into a separate named graph. The name of that graph should be the IRI of the catalog record.
cygri: That tries to explain how the differnet identifiers canplay together
<Makx> +q
<fadmaa> +1
Makx: This sounds a little like an OAI ?? has to be. Are people familiar with that?
cygri: Yes, it does sound like that
Makx: It makes it explicit that different things can be related. It doesn't use the URI of one of the elements - it creates a new URI for the collection
cygri: We're saying that if you already have a Web page that describes the dataset, then you can just use that
<Makx> http://www.openarchives.org/ore/
<cygri> current text:
<cygri> In web-based catalogs, the URL of the catalog page should be used as URI for the catalog record if it is a permalink.
<cygri> If named graphs are used, all RDF triples describing the catalog record, the dataset, and its distributions, should go into a graph named with the catalog record's URI.
PROPOSED RESOLUTION: resolve ISSUE-11 by replacing the current text with the text proposed in http://lists.w3.org/Archives/Public/public-gld-wg/2013Mar/0073.html
<Makx> +q
Makx: I believe that named graphs is still not resolved?
cygri: It's been in SPARQL for about 5 years and will be in RDF 1.1 as part of the Core. It's going to be a Last Call pretty soon. The named graph part is stable
PhilA: Does this create a dependency on RDF 1.1?
cygri: It's in line with
SPARQL
... we could point to that
... or make it informative
PhilA: You can refer to SPARQL and 'informatively' to RDF 1.1
<Makx> fine with me
cygri: We could refer to SPARQL now and maybe change the reference in future
<cygri> PROPOSAL: resolve ISSUE-11 by replacing the current text with the text proposed in http://lists.w3.org/Archives/Public/public-gld-wg/2013Mar/0073.html but refer to SPARQL instead of RDF 1.1 for RDF Dataset and Named Graphs
<cygri> +1
<martin_> +1
+1
<atemezin> +1
<fadmaa> +1
RESOLUTION: Close ISSUE-11 by replacing the current text with the text proposed in http://lists.w3.org/Archives/Public/public-gld-wg/2013Mar/0073.html but refer to SPARQL instead of RDF 1.1 for RDF Dataset and Named Graphs
<cygri> ISSUE-14?
<trackbot> ISSUE-14 -- add dcat:permanentIdentifier property -- open
<trackbot> http://www.w3.org/2011/gld/track/issues/14
cygri: This was raised when we
discussed DCAT with people working on federated catalogues -
national federation of local and so on
... you might get the same record from 2 different places. You
need a way to say they're the same
<Makx> +q
<fadmaa> The dcat:permanentIdentifier property conveys a permanent, globally unique identifier for a dataset. When a DCAT description of a dataset is relocated, syndicated, or republished, the contents of the dcat:permanentIdentifier property MUST NOT change. In other words, the identifier pertains to any occurrence of this same dataset in any catalog, even where dataset descriptions may be exchanged between catalogs and the dataset IRI may change in the process. The value
Makx: We had a situation in
Europeana - you;re getting into the issue of whether 2 things
re the same that have different URIs
... this doesn't do what you were just saying
cygri: If you have a network of
different catalogues, you end up with 2 copies of the same
record
... different catalogues might describe the same thing without
any knowledge of the other
Makx: So your proposal is about
the first catalogue record
... You get into the issue where you need to compare
records
cygri: Yes, but it's helpful if you know it's the same record, or supposed to be
Makx: Who assigns that permanent ID?
<atemezin> Not sure I understand this issue..could it be resolved using the provenance info when agregating records in dataset?
cygri: The original owner of the record
<fadmaa> permanentIdentifier is particularly helpful for aggregator... it is a propert that should not be changed by the aggregator if it exists in the original data
<martin_> (I have no particular opinion on this)