; unless you can use something like N3.
Sven
Von: Pat Hayes
Gesendet: Dienstag, 11. Juni 2013 00:00
An: Sven R. Kunze
On Jun 10, 2013, at 2:15 PM, Sven R. Kunze wrote:
>>> 2)
>>>> - value uknown (it should be there but the source doesn't know it)
>>> Actually that piece of information could be written down in a
RDF Schema graph like this:
>>
>> It can be written far more simply in RDF just by using a blank node:
>>
>> :a :p _:x .
>
> Very interesting and very simple!
>
>
> However, I am not quite sure, whether or not it has the same semantics.
Well, the RDF semantics of this is that something exists that :a
bears the :p relation to, but you don't (yet) know what it is.
Isn't that what you said, above?
> The schema part might not be able to carry the blank node for
each possible future instance.
>
> I could even imagine an entailment rule like this:
> { p rdf:type rdfs:RequiredProperty; rdfs:domain A. x rdf:type A }
=> { x p [] }
> but the other way round might not sensible, I think.
>
>
> Cheers,
> Sven
>
>
>>
>> Pat Hayes
>>
>>>
>>> #schema
>>> :A a rdfs:Class.
>>> :p a rdf:Property; a rdfs:RequiredProperty; rdfs:domain :A.
>>>
>>> #instance
>>> :x a :A; :p :y. # << :x is carries required property
>>> :z a :A. # << :z does not carry required property
>>>
>>> Point here is, that instances cannot "decide" whether or not
they have to carry properties or not. The fact, that :z should
carry a :p property but doesn't consists of two distince pieces of
information:
>>> - :z should carry :p <<< schema information
>>> - :z does not carry :p <<< instance information
>>>
>>>
>>> 3)
>>>> - value doesn't exist (e.g. year of death for a person alive)
>>> I am not quite sure whether this variant is a distinct one or
either falls into 1) or 2).
>>> Maybe that use case is inappropriate to explain what you really
mean by "doesn't exist".
>>> I tend to say that for such instances of persons they could
carry rdfs:inapplicableProperty properties for the properties in
question.
>>>
>>>
>>> 4)
>>>> - value is witheld (access not allowed)
>>> Interesting case, I'd say. I think here we should talk about
access granularity. First, I'd like to have a real usage scenario.
Second, I might have security consideration: it is really necessary
that we tell an untrusted requester whether we don't have that
information or we do not want to give it to him? Third, taken that
under consideration what could a trustworthy requester do with such
information?
>>>
>>> Besides such considerations, I think in this case we should
rethink the way we deliver data. It is not really the subject :s
which is in a relationship :p of an value that signifies
"being-withheld", so:
>>> :x :p rdfs:noAccess, rdfs:withheld, ...
>>> doesn't seem appropriate to me.
>>>
>>> It is the requester that influences the delivered data, not the subject:
>>> @prefix :sec <...> <<< security namespace
>>>
>>> [] a sec:PropertyWithheld;
>>> sec:requester <....>;
>>> # sec:instance :s; << optional as generally all subjects
with that particular property can be withheld
>>> sec:property :p.
>>>
>>> ----------------------------------------------------------------
>>>
>>> What about composite values like in
>>> :foo :aProp [a :nullableValue; rdf:value "value"] ;
>>> :bProp [a :nullableValue; :reason :notAvailable ].
>>>
>>> First of all, I do not really know why we have to merge schema
information into instance data.
>>> Second, there is a second level of graph traversal, which I
preferably would like to avoid as it clutters up queries and the
triple store.
>>> Third, most of your given examples are schema design issues
(there might be more examples) can be solved without introducing a
clumsy composite value.
>>> Forth, a composite values disturbs the data design when there
are "normal" values which can be expressed via "normal" literals,
URIs, bnodes. That is, the access queries differ from property to
property which should be avoided as it complifies(??) a lot.
>>>
>>> Cheers,
>>> Sven
>>>
>>>
>>>
>>>
>>>
>>
>> ------------------------------------------------------------
>> IHMC (850)434 8903 or (650)494 3973
>> 40 South Alcaniz St. (850)202 4416 office
>> Pensacola (850)202 4440 fax
>> FL 32502 (850)291 0667 mobile
>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
>
>
> --
> Sven R. Kunze
> Chemnitz University of Technology
> Department of Computer Science
> Distributed and Self-organizing Systems Group
> Straße der Nationen 62
> D-09107 Chemnitz
> Germany
> E-Mail: [email protected]
> WWW: http://vsr.informatik.tu-chemnitz.de/people/kunze
> Phone: +49 371 531 33882
>
>
>
------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 mobile
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
