Re: fundamental issues

1) Schema.org uses their own version/interpretation of what domain and
range are which is different from RDFS. It is not interpreting them more
loosely, it interprets them differently.

In RDFS, when a property has two classes in its domain, it means that the
subject of a triple with that property as a predicate belongs to both
classes. Schema. org says that the subject can be a member of any one of
the classes. In fact, they created their own properties
schema:domainIncludes and shema:rangeIncludes. LDOM takes a similar
approach.

2) I don't understand how this question relates to data validation. At the
point when data is validated, one has to make a closed world assumption.
What happens before and after validation, is a different matter. Other
processes could assume open world. This does not in any way interfere with
each other.

Irene

On Fri, Feb 13, 2015 at 10:08 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> 1) schema.org does use the concepts of domains and ranges, extensively,
> but it defines them more loosely than RDFS. They are fundamental to
> schema.org
>
> 2) are you assuming that your data is closed-world only? If it is not, are
> there implications to this use of rdfs:Class in the open world?
>
> kc
>
>
> On 2/13/15 6:35 AM, Irene Polikoff wrote:
>
>> I think we agree. They don't contribute anything to validation, but if
>> people want to use them that is OK. From the data definition/data
>> validation perspective they will be ignored.
>>
>> Irene
>>
>> Sent from my iPhone
>>
>>  On Feb 13, 2015, at 7:15 AM, Peter F. Patel-Schneider <
>>> pfpschneider@gmail.com> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> I don't see that this is any reason to not let people who want domain and
>>> range to use domain and range.  If some people don't want domain and
>>> range
>>> then the solution for them is simple - they don't need to use domain and
>>> range.
>>>
>>> peter
>>>
>>>
>>>  On 02/13/2015 02:18 AM, Irene Polikoff wrote:
>>>> The reason to exclude domain and range is the same reason why Schema.org
>>>> excluded them. They don't work in a way that is useful to a community
>>>> interested in specifying what data should look like.
>>>>
>>>> In addition to not being useful, they also create problems by
>>>> intersecting multiple ranges and domains, etc. They are often misused.
>>>>
>>>> So, one could call this RDFS- data. I don't think domains and ranges
>>>> must
>>>> be prohibited though, they could just be ignored.
>>>>
>>>> Irene
>>>>
>>>>  On Feb 12, 2015, at 10:08 PM, Peter F. Patel-Schneider
>>>>> <pfpschneider@gmail.com> wrote:
>>>>>
>>>> I suppose that the working group could exclude rdfs:domain and
>>>> rdfs:range from the RDF graphs that it considers to be acceptable, just
>>>> as OWL DL excluded certain RDF graphs.  For OWL DL that was to achieve
>>>> decidability and I don't see an equivalent need here.
>>>>
>>>> peter
>>>>
>>>>
>>>>  On 02/12/2015 04:03 PM, Holger Knublauch wrote:
>>>>>>>> On 2/13/2015 8:19, Peter F. Patel-Schneider wrote: Is the working
>>>>>>>> group producing a solution tailored for RDF data, where RDF
>>>>>>>> graphs and rdf:type are important; for RDFS data, where
>>>>>>>> rdfs:subClassOf, rdfs:subPropertyOf, rdfs:domain, and rdfs:range
>>>>>>>> are also important; for Linked Data, where dereferencing and
>>>>>>>> interlinking is important; or for services data, where brevity
>>>>>>>> may be important?
>>>>>>>>
>>>>>>>> 2. Shapes and Classes
>>>>>>>>
>>>>>>>> Are shapes RDF classes, i.e., should shapes be the object of
>>>>>>>> rdf:tyoe triples, participate in rdfs:subClassOf relationships,
>>>>>>>> and be the object of rdfs:domain and rdfs:range triples?
>>>>>>>>
>>>>>>>
>>>>>>> In both points you seem to assume that if we use rdfs:subClassOf
>>>>>>> then we also must use rdfs:domain and rdfs:range. Could you
>>>>>>> clarify? I would assume it is possible to use parts of the RDFS
>>>>>>> namespace without sucking in all dependencies, assuming we clarify
>>>>>>> that situation in the beginning of the specification.
>>>>>>>
>>>>>>> Thanks, Holger
>>>>>>>
>>>>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1
>>>
>>> iQEcBAEBAgAGBQJU3ertAAoJECjN6+QThfjz+8cH/3lpq+zfMg09M01sCRIlDqi1
>>> nslsOObD4ukEuioL/f9GQ1/OZvcZVw6i09aNugsABbUHfTuFUIxsmGA9+6r1ZM+t
>>> kVqzewSPhH4GFp5Gcy8x4Y0pAIEBQ62RRYfPNClX38eFx5e/ZJ+xfg5HSjqzpF3r
>>> xVuW1+i5nge0lUJr4WF/bW/Tj6g69TXUrXet3tNTJ1sddkxqXPo7jBvSE1kZkBTH
>>> 3UsZr1yokiM6FkbxI1JJ6MIOl1BdvBvwQaiyn38fgMjNSvTTtfvhnp3Mua8Ss4He
>>> 3hExQ4wUMXw0nU4ob+71dqzvaU1o9hgRlxwgSky4gXOAmD95U84fgpUZuVxDKWs=
>>> =KorL
>>> -----END PGP SIGNATURE-----
>>>
>>
>>
>>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>
>