- From: Michael Brunnbauer <brunni@netestate.de>
- Date: Sun, 25 Mar 2012 00:16:46 +0100
- To: Jeni Tennison <jeni@jenitennison.com>
- Cc: James Leigh <james@3roundstones.com>, public-lod community <public-lod@w3.org>
Hello Jeni, so every publisher who wants to provide licencing information for his RDF has to either 1) use 303 redirects 2) publish no data at the NIR except the describedby triples, which seems pointless to me 3) use the same URI for the IR and the NIR If he also wants to provide meta information for his HTML, he cannot publish the HTML at the NIR. I don't see a new and easier option offered by the proposal. In the end, people will do what they already do today. BTW: The POWDER describedby property suggests that you will find some information about the subject of the describedby triple when you dereference the object URI but this does not seem to be intended here. POWDER with it's power to assert metadata for whole collections of IRs also probably will contribute to the IR/NIR conflation. I think we should leave everything as it is and just don't blame publishers who conflate IRs and NIRs. Sooner or later, they probably will fix it all. Regards, Michael Brunnbauer On Sat, Mar 24, 2012 at 10:43:10PM +0000, Jeni Tennison wrote: > Michael, > > On 24 Mar 2012, at 21:59, Michael Brunnbauer wrote: > > On Sat, Mar 24, 2012 at 09:04:14PM +0000, Jeni Tennison wrote: > >> I suspect that consumers won't want to make any assumptions and will just hoover up all the data that they can from wherever they can. > >> I suspect that publishers will mostly want to provide just information about the probe URI at the probe URI, and more details about licensing/provenance at the description URIs. > > > > But the licensing information refers to the description URI. What are the > > conditions for the data available at the probe URI ? Do we have to introduce > > some rule that if X describedby Y, then every licencing/provenance information > > at Y also holds for X ? Will the courts see it this way, too ? > > > If you are a consumer who cares about the license of the data you're crawling (and yes, I think every consumer should but no I don't think every consumer does), the only thing that you can rely on is that if you somehow know that U is an information resource (eg it's the target of a describedby link or you got there through a 303) and a license has been asserted for U then the information within the document you get at U is licensed under that license. > > So in the case above, you have to assume that the license about Y only applies to the data available at Y. You can only have information about the license of the data that is returned when you resolve X if you know that X is an information resource too (eg if X contains a statement in which it is the object of a :describedby relationship). > > This leads to more accurate inferences about licensing than the current state of affairs where we go to http://www.flickr.com/photos/inju/3192446387/ and find: > > <http://www.flickr.com/photos/inju/3192446387/> > dcterms:title "Can you help? My K2 Sidebar Manager is screwy" ; > dcterms:date "January 12, 2009" ; > dcterms:creator <http://www.flickr.com/photos/inju/> ; > cc:attributionURL <http://www.flickr.com/photos/inju/> ; > cc:license <http://creativecommons.org/licenses/by-nc-sa/2.0/deed.en> ; > . > > and all of the information, including the license, is actually about the photograph identified by http://www.flickr.com/photos/inju/3192446387/ and not the HTML page or the data it contains, which is in fact covered by http://info.yahoo.com/legal/uk/yahoo/utos-173.html. > > Cheers, > > Jeni > -- > Jeni Tennison > http://www.jenitennison.com > -- ++ Michael Brunnbauer ++ netEstate GmbH ++ Geisenhausener Straße 11a ++ 81379 München ++ Tel +49 89 32 19 77 80 ++ Fax +49 89 32 19 77 89 ++ E-Mail brunni@netestate.de ++ http://www.netestate.de/ ++ ++ Sitz: München, HRB Nr.142452 (Handelsregister B München) ++ USt-IdNr. DE221033342 ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
Received on Saturday, 24 March 2012 23:17:11 UTC