Re: License unknown

     Hello,

On Fri, Jun 20, 2014 at 3:16 PM, Joachim Baran <joachim.baran@gmail.com>
wrote:

>   I had a read through our note again and think that a boolean property
> would be an odd one out.
>
>   I would consider Jerven's solution (simply omitting the information) or
> Michel's solution (using a label) to be more suitable.
>
>   If we were to use a label, it could be appropriated as 'rdfs:label
> "Please contact EBI for available licenses."'.
>

  Also, makes me wonder why the EBI has not already been contacted and the
license determined? Is that because we didn't have the resources to do so
or because different end users might end up being granted different
licenses?

     Best,
     Oliver


>
>   With a boolean solution -- especially when it only denotes whether
> license lookup was tried -- it is not clear what information that bears.
> Why would this boolean ever be set to false? Regardless of it's state, what
> does it imply? It provides no further information than omitting the
> explicit licensing statement (Jerven's solution) and it does not provide
> extra labeling (Michel's solution).
>
> Kim
>
>
> On 18 June 2014 11:06, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:
>
>> Yes, mostly. I'm also trying to adhere to the ideal of having the semweb
>> assertions being a monotonically increasing set. At the moment the
>> semantics of the reasoning tools assume monotonicity. For an example of the
>> problem, consider a resource which makes inferences based on assertions
>> other make. Keeping their resource up-to-date is much harder if they have
>> to keep checking if assertions have disappeared, and then run their
>> reasoning process again from the start.
>>
>> -Alan
>>
>>
>> On Wed, Jun 18, 2014 at 2:01 PM, M. Scott Marshall <
>> mscottmarshall@gmail.com> wrote:
>>
>>> Ah, got it. I was creating the same problem that you were attempting
>>> to fix: You want to make it impossible to add an inconsistent
>>> assertion in the case that the license is initially unknown but is
>>> determined later by building the safe guard into the property. That
>>> seems reasonable enough.. although we (Alasdair and maybe more?) are
>>> creating a validator, as well as an editor (building on the VOID
>>> editor) which would prevent such inconsistencies anyway. Still, it
>>> solves the problem of being able to require that data publishers
>>> actually *try* to determine the license in order to meet our
>>> specification without going against best (?) 'open world' practices,
>>> where unstated = unknown. It also avoids the problem of strictly
>>> limiting datasets to 1 license - probably too restrictive.
>>>
>>> A small doubt: it's still possible to create an inconsistency when
>>> :tried-to-determine-license "false"^xsd:Boolean but dc:license has a
>>> valid license as value.
>>>
>>> Alasdair, Eric - Is there anything in the proposed solution that
>>> http://www.w3.org/2013/ShEx/Primer cannot catch?
>>>
>>> Jerven - does it handle your objections?
>>>
>>> -Scott
>>>
>>>
>>> On Wed, Jun 18, 2014 at 3:06 PM, Alan Ruttenberg
>>> <alanruttenberg@gmail.com> wrote:
>>> > The reason I labeled it tried-to-determine-license is that that way the
>>> > assertion remains true. If the predicate is whether we *have*
>>> determined
>>> > license then the assertion needs to be retracted when we do. When
>>> possible
>>> > we try to make statements that remain true.
>>> >
>>> > When probing for a license, first check dc:license, and if it is
>>> absent,
>>> > check :tried-to-determine-license.
>>> >
>>> > In user interfaces there's no reason to show both. It's perfectly
>>> reasonable
>>> > to use these properties to decide whether to show "License: Unknown"
>>> >
>>> > -Alan
>>> >
>>> >
>>> > On Wed, Jun 18, 2014 at 8:46 AM, M. Scott Marshall
>>> > <mscottmarshall@gmail.com> wrote:
>>> >>
>>> >> Just a slight tweak to Alan's suggestion (thanks Alan):
>>> >> :determined-license "true"^xsd:Boolean
>>> >>
>>> >> -Scott
>>> >>
>>> >> On Wed, Jun 18, 2014 at 2:36 PM, Alan Ruttenberg
>>> >> <alanruttenberg@gmail.com> wrote:
>>> >> > I concur. This is clear from the semantics of OWL. Understand the
>>> >> > difference
>>> >> > between integrity constraints and OWL assertions.
>>> >> >
>>> >> > If you want to say that there was an attempt to find a license and
>>> that
>>> >> > it
>>> >> > couldn't be found, say that. You could do so as an annotation on the
>>> >> > axiom,
>>> >> > or as a distinct property e.g.
>>> >> > :tried-to-determine-license "true"^xsd:Boolean
>>> >> >
>>> >> > This can remain true, as a historical fact, even after a license is
>>> >> > found.
>>> >> >
>>> >> > For more about integrity constraints see
>>> >> > http://clarkparsia.com/pellet/icv/
>>> >> >
>>> >> > -Alan
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Monday, June 16, 2014, Jerven Bolleman <me@jerven.eu> wrote:
>>> >> >>
>>> >> >> Hi Alasdair,
>>> >> >>
>>> >> >> I think you are closing the world the wrong way. Both in limiting a
>>> >> >> dataset to have one license and secondly by having an "unknown"
>>> string
>>> >> >> to encode that you don't know something.
>>> >> >> Instead of using "unknown" you should use a blank node.
>>> >> >>
>>> >> >> cc:CC0 owl:sameAs "unknown"
>>> >> >>
>>> >> >> is plain wrong and can't be inferred
>>> >> >>
>>> >> >> cc:CC0 owl:sameAs _:1
>>> >> >>
>>> >> >> is fine and a nice way of allowing dataset from different sources
>>> >> >> descriptions to be combined and give more information.
>>> >> >>
>>> >> >> If you don't want a blank node, make a local node instead.
>>> >> >> cc:CC0 owl:sameAs <./#license>
>>> >> >>
>>> >> >> I implore you to change your mind on this. Choose semantics over
>>> >> >> special
>>> >> >> values!
>>> >> >>
>>> >> >> Regards,
>>> >> >> Jerven
>>> >> >>
>>> >> >>
>>> >> >> On Mon, Jun 16, 2014 at 5:44 PM, Gray, Alasdair J G
>>> >> >> <A.J.G.Gray@hw.ac.uk>
>>> >> >> wrote:
>>> >> >> > Hi Jerven,
>>> >> >> >
>>> >> >> > We are trying to ensure that a license is provided for a
>>> dataset, and
>>> >> >> > that
>>> >> >> > only one license is provided. (We are closing the world in
>>> certain
>>> >> >> > areas.)
>>> >> >> >
>>> >> >> > Our proposed solution is written up at
>>> >> >> > https://github.com/joejimbo/HCLSDatasetDescriptions/issues/65
>>> >> >> >
>>> >> >> > Alasdair
>>> >> >> >
>>> >> >> > On 2 Jun 2014, at 16:47, Jerven Bolleman <me@jerven.eu> wrote:
>>> >> >> >
>>> >> >> > Hi Alasdair,
>>> >> >> >
>>> >> >> > It is good practice in my opinion to not state unknown facts. If
>>> you
>>> >> >> > want to state there should be a license but you don't know it I
>>> think
>>> >> >> > some owl modelling is called for.
>>> >> >> >
>>> >> >> > e.g. roughly like this.
>>> >> >> >
>>> >> >> > dusty_data a dct:Dataset .
>>> >> >> > dusty_data rdfs:subClassOf [ a owl:Restriction ;
>>> >> >> >                                            owl:onProperty
>>> dct:license
>>> >> >> > ;
>>> >> >> >                                            owl:minCardinality 1 ]
>>> >> >> >
>>> >> >> >
>>> >> >> > If anyone does something like
>>> >> >> >
>>> >> >> > dusty_data a dct:dataset .
>>> >> >> > dusty_data dct:license bad_example:unknown_license .
>>> >> >> >
>>> >> >> > and then someone figures out it has a license .
>>> >> >> >
>>> >> >> > dusty_data a dct:Dataset .
>>> >> >> > dusty_data dct:license cc:zero .
>>> >> >> >
>>> >> >> > And puts all those triples into one store/ontology then queries
>>> will
>>> >> >> > start to return wrong data.
>>> >> >> >
>>> >> >> > SELECT ?datasetWithALicense
>>> >> >> > WHERE {
>>> >> >> > ?datasetWithALicense dct:license ?license .
>>> >> >> > }
>>> >> >> >
>>> >> >> > Will give 2 bindings for ?dataset and ?license one of them being
>>> >> >> > wrong
>>> >> >> > now.
>>> >> >> >
>>> >> >> > If you ask the same question depending on the better modelling
>>> then
>>> >> >> > you get the correct answer in both cases.
>>> >> >> >
>>> >> >> > SELECT ?datasetWIthoutLicense
>>> >> >> > WHERE {
>>> >> >> > ?datasetWIthoutLicense a dct;Dataset .
>>> >> >> > MINUS ( ?datasetWIthoutLicense dct:license ?license )
>>> >> >> > }
>>> >> >> >
>>> >> >> > SELECT ?datasetWIthALicense
>>> >> >> > WHERE {
>>> >> >> > ?datasetWIthALicense a dct;Dataset .
>>> >> >> > ?datasetWIthALicense dct:license ?license .
>>> >> >> > }
>>> >> >> >
>>> >> >> > Both give the expected results.
>>> >> >> >
>>> >> >> >
>>> >> >> > In general in RDF just state what you know and describe what you
>>> >> >> > don't
>>> >> >> > know.
>>> >> >> >
>>> >> >> > Regards,
>>> >> >> > Jerven
>>> >> >> >
>>> >> >> > On Mon, Jun 2, 2014 at 5:25 PM, Gray, Alasdair J G
>>> >> >> > <A.J.G.Gray@hw.ac.uk>
>>> >> >> > wrote:
>>> >> >> >
>>> >> >> > Hi,
>>> >> >> >
>>> >> >> > I am working to help shape the Healthcare and Life Sciences
>>> community
>>> >> >> > profile for describing datasets, current version available from
>>> [1]
>>> >> >> >
>>> >> >> > One of our goals is that there is a minimal set of properties
>>> that
>>> >> >> > are
>>> >> >> > available for all datasets, and we would like these properties to
>>> >> >> > include
>>> >> >> > the license. However we have the problem that for several legacy
>>> >> >> > datasets
>>> >> >> > the license is simply unknown. Does anyone know of a resource
>>> that
>>> >> >> > can
>>> >> >> > be
>>> >> >> > used to represent that the license is unknown as the value of a
>>> >> >> > dcterms:license predicate?
>>> >> >> >
>>> >> >> > Thanks
>>> >> >> >
>>> >> >> > Alasdair
>>> >> >> >
>>> >> >> > [1] https://github.com/joejimbo/HCLSDatasetDescriptions
>>> >> >> >
>>> >> >> > Alasdair J G Gray
>>> >> >> > Lecturer in Computer Science, Heriot-Watt University, UK.
>>> >> >> > Email: A.J.G.Gray@hw.ac.uk
>>> >> >> > Web: MailScanner has detected a possible fraud attempt from
>>> >> >> > "www.macs.hw.ac.uk" claiming to be
>>> http://www.alasdairjggray.co.uk
>>> >> >> > ORCID: http://orcid.org/0000-0002-5711-4872
>>> >> >> > Telephone: +44 131 451 3429
>>> >> >> > Twitter: @gray_alasdair
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > ________________________________
>>> >> >> >
>>> >> >> > Sunday Times Scottish University of the Year 2011-2013
>>> >> >> > Top in the UK for student experience
>>> >> >> > Fourth university in the UK and top in Scotland (National Student
>>> >> >> > Survey
>>> >> >> > 2012)
>>> >> >> >
>>> >> >> > We invite research leaders and ambitious early career
>>> researchers to
>>> >> >> > join us
>>> >> >> > in leading and driving research in key inter-disciplinary themes.
>>> >> >> > Please
>>> >> >> > see
>>> >> >> > www.hw.ac.uk/researchleaders for further information and how to
>>> >> >> > apply.
>>> >> >> >
>>> >> >> > Heriot-Watt University is a Scottish charity registered under
>>> charity
>>> >> >> > number
>>> >> >> > SC000278.
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > --
>>> >> >> > Jerven Bolleman
>>> >> >> > me@jerven.eu
>>> >> >> >
>>> >> >> >
>>> >> >> > Alasdair J G Gray
>>> >> >> > Lecturer in Computer Science, Heriot-Watt University, UK.
>>> >> >> > Email: A.J.G.Gray@hw.ac.uk
>>> >> >> > Web: MailScanner has detected a possible fraud attempt from
>>> >> >> > "www.macs.hw.ac.uk" claiming to be
>>> http://www.alasdairjggray.co.uk
>>> >> >> > ORCID: http://orcid.org/0000-0002-5711-4872
>>> >> >> > Telephone: +44 131 451 3429
>>> >> >> > Twitter: @gray_alasdair
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > ________________________________
>>> >> >> >
>>> >> >> > Sunday Times Scottish University of the Year 2011-2013
>>> >> >> > Top in the UK for student experience
>>> >> >> > Fourth university in the UK and top in Scotland (National Student
>>> >> >> > Survey
>>> >> >> > 2012)
>>> >> >> >
>>> >> >> > We invite research leaders and ambitious early career
>>> researchers to
>>> >> >> > join us
>>> >> >> > in leading and driving research in key inter-disciplinary themes.
>>> >> >> > Please
>>> >> >> > see
>>> >> >> > www.hw.ac.uk/researchleaders for further information and how to
>>> >> >> > apply.
>>> >> >> >
>>> >> >> > Heriot-Watt University is a Scottish charity registered under
>>> charity
>>> >> >> > number
>>> >> >> > SC000278.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Jerven Bolleman
>>> >> >> me@jerven.eu
>>> >> >>
>>> >>
>>> >> --
>>> >> M. Scott Marshall, PhD
>>> >> MAASTRO clinic, http://www.maastro.nl/en/1/
>>> >> http://eurecaproject.eu/
>>> >> http://semantic-dicom.org/
>>> >> https://plus.google.com/u/0/114642613065018821852/posts
>>> >> http://www.linkedin.com/pub/m-scott-marshall/5/464/a22
>>>
>>
>>
>


-- 
Oliver Ruebenacker
Founder at Relomics Consulting <http://www.relomics.com>
Be always grateful, but never satisfied.

Received on Friday, 20 June 2014 19:41:38 UTC