[Crm-sig] Parent of F4 Manifestation Singleton

2018-09-10 Thread Athanasios Velios

Dear all,

I looked through the mailing list archive but could not find an answer for:

Why is F4 Manifestation Singleton a child of E24 and not a child of E22?

Its scope note starts with: "This class comprises physical objects..."
and we are always talking about a carrier. Are there any examples of
features-carriers that I can't think of? If, when scratching a poem on a
rocky mountain, the mountain is considered a carrier, then I think we
should update the scope note to reflect that.

All the best,

Thanasis
This email and any attachments are intended solely for the addressee and may 
contain confidential information. If you are not the intended recipient of this 
email and/or its attachments you must not take any action based upon them and 
you must not copy or show them to anyone. Please send the email back to us and 
immediately and permanently delete it and its attachments. Where this email is 
unrelated to the business of University of the Arts London or of any of its 
group companies the opinions expressed in it are the opinions of the sender and 
do not necessarily constitute those of University of the Arts London (or the 
relevant group company). Where the sender's signature indicates that the email 
is sent on behalf of UAL Short Courses Limited the following also applies: UAL 
Short Courses Limited is a company registered in England and Wales under 
company number 02361261. Registered Office: University of the Arts London, 272 
High Holborn, London WC1V 7EY



Re: [Crm-sig] Issue: Solution for Dualism of E41 Appellation and rdfs:label

2018-09-10 Thread Mark Fichtner
Dear all,

the main question for me is: Is the use of rdf:label in this case really
the intended way by the CIDOC CRM? In fact P1 currently has a valid range
and E41 is a valid class and not a primitive datatype. Why should we
substitute this?

I agree with Martin that we should integrate old data that has a different
model and therefore the proposal and the work is very nice to see. However
I think we should have exactly one best practice. At the GNM we typically
have regular instances of E41, which in my eyes follows the CIDOC CRM
better, so I would love to see this in the best practice.

Best,

Mark Fichtner

2018-09-04 21:29 GMT+02:00 Robert Sanderson :

> Hi Detlev,
>
>
>
> Apologies, I meant that the pattern makes it more complicated to
> understand, as opposed to it being ambiguous in the data (which would be
> much worse!). More difficult for a human rather than for the machine :)
>
>
>
> For example, in JSON-LD, it would result in
>
>
>
> {
>
>   “P1_is_identified_by”: [
>
>   “uri-as-string”,
>
>   {
>
>  “@id”: “uri-as-identifier”
>
>   }
>
>   ]
>
> }
>
>
>
> Which then makes developers cross, as there are mixed data types in the
> array, and the current specification doesn’t allow the string to be
> expressed in an object with only @value as a key.
>
>
>
> Currently that would be the simpler compaction of:
>
>
>
> {
>
>   “P1_is_identified_by: [
>
>   “uri-as-identifier”
>
>   ]
>
> }
>
>
>
> Because P1 can only ever have a resource as its object.
>
>
>
> Or (if you don’t care for the singleton array), the simplest possible form:
>
>
>
> {
>
>   “P1_is_identified_by”: “uri-as-identifier”
>
> }
>
>
>
> Rob
>
>
>
> *From: *Crm-sig  on behalf of Detlev Balzer
> 
> *Date: *Tuesday, September 4, 2018 at 12:11 PM
> *To: *"crm-sig@ics.forth.gr" 
> *Subject: *Re: [Crm-sig] Issue: Solution for Dualism of E41 Appellation
> and rdfs:label
>
>
>
> Am 04.09.2018 um 19:19 schrieb Robert Sanderson:
>
> In particular, it makes it difficult in several serializations to
> distinguish between the string “http://example.museum.org/data/1” and the
> resource that has the URI http://example.museum.org/data/1 as its
> identifier.
>
>
>
> Which ones do you mean? All the serializations I've seen make clear
> syntactic distinctions between literals and URIs.
>
>
>
> While I agree that "punning" is bad practice, I don't see why it should
> confuse RDF software tools.
>
>
>
> Detlev
>
>
>
>
>
> Am 04.09.2018 um 19:19 schrieb Robert Sanderson:
>
>
>
> Dear all,
>
>
>
> Please no!  This is called “punning” (when the same property can be have
> both literals and resources as its range) and is widely recognized as a bad
> practice in RDF.
>
>
>
> In particular, it makes it difficult in several serializations to
> distinguish between the string “http://example.museum.org/data/1” and the
> resource that has the URI http://example.museum.org/data/1 as its
> identifier.
>
>
>
> Rob
>
>
>
>
>
> *From: *Crm-sig  on behalf of Martin Doerr <
> mar...@ics.forth.gr>
>
> *Date: *Saturday, September 1, 2018 at 7:41 AM
>
> *To: *crm-sig 
>
> *Subject: *[Crm-sig] Issue: Solution for Dualism of E41 Appellation and
> rdfs:label
>
>
>
> Dear All,
>
> Obviously, there are two ways in RDF to express what the CRM regards as an
> Appellation: Either using a URI, instance of E41, and then another property
> specifying in whatever way the symbolic content (I am not concerned with
> this here), *OR *using rdfs:label, which has exactly the meaning of some
> forms of Appellation that can be expressed exhaustively as literal.
>
> Interesting enough, there seems to be no existing validation method, that
> would exclude any instance of xsd Datatype to be used as range of
> rdfs:label.
>
> We have made therefor the following tests with Virtuoso, if P1 can have
> two ranges, Literal and E41, and if SPARQL gives the expected answers, it
> does:
>
> *1.**  **Dualism of Appellations*
>
> The purpose of this is to provide an *RDF based technical solution* for
> representing and querying a property which can be at the same time Data and
> Object type regardless of the fact that it violates the respective
> constraints or rules.
>
> Practically we can have three options of representing appellations. By
> taking the example of Alexander the Great with supposed URI:
> http://example.com/person/alexander_the_great we can do the following:
>
> 1)  Use the “P1 is identified by” property and an instance of E41
> Appellation class:
>
>
>
>  <
> http://example.com/person/alexander_the_great>
>
> crm:P1_is_identified_by
>
>   appellation/alexander_the_great> .
>
>
>
>   appellation/alexander_the_great>
>
> rdfs:label
>
> "Alexander the Great" .
>
>
>
> 2)  Use directly the rdfs:label:
>
>  <
> htt

Re: [Crm-sig] Issue: Solution for Dualism of E41 Appellation and rdfs:label

2018-09-10 Thread George Bruseker
Dear all,

I am a fan of the traditional solution:

1) E1 -> p1 -> E41 

here the encoding all the way down to a value would be rdfs:value VALUE because 
we want to track the actual string used to represent the name (separate from 
the URI of the name)

We use this solution whenever we want to name something about which we care for 
the name (much of the time)

2) rdfs:label Value

This should be used on all nodes to give a human readable label. This is often 
enough if we don’t study the names used.

Best,

George

--
Dr. George Bruseker
R & D Engineer

Centre for Cultural Informatics
Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)
Science and Technology Park of Crete
Vassilika Vouton, P.O.Box 1385, GR-711 10 Heraklion, Crete, Greece

Tel.: +30 2810 391619   Fax: +30 2810 391638   E-mail: bruse...@ics.forth.gr
URL: http://www.ics.forth.gr/isl

> On Sep 10, 2018, at 5:06 PM, Mark Fichtner  wrote:
> 
> Dear all,
> 
> the main question for me is: Is the use of rdf:label in this case really the 
> intended way by the CIDOC CRM? In fact P1 currently has a valid range and E41 
> is a valid class and not a primitive datatype. Why should we substitute this?
> 
> I agree with Martin that we should integrate old data that has a different 
> model and therefore the proposal and the work is very nice to see. However I 
> think we should have exactly one best practice. At the GNM we typically have 
> regular instances of E41, which in my eyes follows the CIDOC CRM better, so I 
> would love to see this in the best practice.
> 
> Best,
> 
> Mark Fichtner
> 
> 2018-09-04 21:29 GMT+02:00 Robert Sanderson  >:
> Hi Detlev,
> 
>  
> 
> Apologies, I meant that the pattern makes it more complicated to understand, 
> as opposed to it being ambiguous in the data (which would be much worse!). 
> More difficult for a human rather than for the machine :)
> 
>  
> 
> For example, in JSON-LD, it would result in
> 
>  
> 
> {
> 
>   “P1_is_identified_by”: [
> 
>   “uri-as-string”,
> 
>   {
> 
>  “@id”: “uri-as-identifier”
> 
>   }
> 
>   ]
> 
> }
> 
>  
> 
> Which then makes developers cross, as there are mixed data types in the 
> array, and the current specification doesn’t allow the string to be expressed 
> in an object with only @value as a key.
> 
>  
> 
> Currently that would be the simpler compaction of:
> 
>  
> 
> {
> 
>   “P1_is_identified_by: [
> 
>   “uri-as-identifier”
> 
>   ]
> 
> }
> 
>  
> 
> Because P1 can only ever have a resource as its object.
> 
>  
> 
> Or (if you don’t care for the singleton array), the simplest possible form:
> 
>  
> 
> {
> 
>   “P1_is_identified_by”: “uri-as-identifier”
> 
> }
> 
>  
> 
> Rob
> 
>  
> 
> From: Crm-sig  > on behalf of Detlev Balzer 
> mailto:d...@balilabs.de>>
> Date: Tuesday, September 4, 2018 at 12:11 PM
> To: "crm-sig@ics.forth.gr " 
> mailto:crm-sig@ics.forth.gr>>
> Subject: Re: [Crm-sig] Issue: Solution for Dualism of E41 Appellation and 
> rdfs:label
> 
>  
> 
> Am 04.09.2018 um 19:19 schrieb Robert Sanderson:
> 
> In particular, it makes it difficult in several serializations to distinguish 
> between the string “http://example.museum.org/data/1 
> ” and the resource that has the URI 
> http://example.museum.org/data/1  as its 
> identifier.
> 
>  
> 
> Which ones do you mean? All the serializations I've seen make clear syntactic 
> distinctions between literals and URIs.
> 
>  
> 
> While I agree that "punning" is bad practice, I don't see why it should 
> confuse RDF software tools.
> 
>  
> 
> Detlev
> 
>  
> 
>  
> 
> Am 04.09.2018 um 19:19 schrieb Robert Sanderson:
> 
>   
> 
> Dear all,
> 
>   
> 
> Please no!  This is called “punning” (when the same property can be have both 
> literals and resources as its range) and is widely recognized as a bad 
> practice in RDF.
> 
>   
> 
> In particular, it makes it difficult in several serializations to distinguish 
> between the string “http://example.museum.org/data/1 
> ” and the resource that has the URI 
> http://example.museum.org/data/1  as its 
> identifier.
> 
>   
> 
> Rob
> 
>   
> 
>   
> 
> *From: *Crm-sig  > on behalf of Martin Doerr 
> mailto:mar...@ics.forth.gr>>
> 
> *Date: *Saturday, September 1, 2018 at 7:41 AM
> 
> *To: *crm-sig mailto:Crm-sig@ics.forth.gr>>
> 
> *Subject: *[Crm-sig] Issue: Solution for Dualism of E41 Appellation and 
> rdfs:label
> 
>   
> 
> Dear All,
> 
> Obviously, there are two ways in RDF to express what the CRM regards as an 
> Appellation: Either using a URI, instance of E41, and then another property 
> specifying in whatever way the symbolic content (I am not concerned with this 
> here), *OR *usin