A One could model this piece of information like this:
:s rdfs:inapplicableProperty :p.
Hmm. What would the semantics of this be? Can you write any
entailment rules for it? I imagine this might be one, for example:
x rdfs:InapplicableProperty p .
x p y .
are unsatisfiable (inconsistent), for any y. Does that capture your
intended meaning adequately? Are there any other entailments that
would be required?
Good point. To be honest, I do not know.
Especially, in this case, I could imagine several alternatives leading
to several different variances of rdfs:inapplicableProperty.
first)
as you have said
second)
no entailment rules at all; just additional data with the following meanings:
a)
s rdfs:inapplicableProperty p.
the data consumer should not expect p so be there in conjunction with
s at anytime (soon)
b)
s rdfs:inapplicableProperty p.
s p y.
there might have been a time where the graph carried only a); but the
data provider forget to remove the a) triple
c)
s p y.
as usual
(Given that RDFS incorporates inapplicableProperty.)
B Another way of modelling would be
:s :p rdfs:inapplicable.
That has the consequence in RDFS that, for example
rdfs:inapplicable rdf:type :A .
when :A is asserted to be an rdfs:range of :p . Would that be acceptable?
Hmm, not sure either. That might be a reason why I would prefer the
former variant.
(Given that RDFS incorporates inapplicable)
I would like to see variant A as the relationship is between the
current subject and a schema element (the property) and not between
the subject and a non-existent value.
A schema could even define rdfs:inapplicableProperties for
constant-instances in order prevent or detect mis-use.
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.
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
